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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the stage 2 service description for a GSM/EDGE Radio Access Network (GERAN). 
ITU-T Recommendation 1.130 describes a three-stage method for characterisation of telecommunication services, and 
CCITT Q.65 defines stage 2 of the method. 

The present document illustrates how the services requested by a GSM/UMTS Core Network are realized by the 
GERAN. 

The main focus of the present document is on functionality related to the lu interfaces. The aim of the present document 
is not to describe functionality related to the A and Gb interfaces in details. There is no detailed description of the 
interfaces towards the core network and only references are given to the appropriate specifications. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

2.1 Normative references 

[ 1 ] 3GPP TS 25 .4 1 0: "UTRAN lu Interface: General Aspects and Principles" . 

[2] 3GPP TS 25.41 1 : "UTRAN lu interface Layer 1 ". 

[3] 3GPP TS 25.412: "UTRAN lu interface signalling transport". 

[4] 3GPP TS 25 .4 1 3 : "UTRAN lu interface RAN AP signalling" . 

[5] 3GPP TS 25.414: "UTRAN lu interface data transport & transport signalling". 

[6] 3GPP TS 25.415: "UTRAN lu interface user plane protocols". 

[7] 3GPP TS 48.014: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN) interface; Gb interface Layer 1". 

[8] 3GPP TS 48.016: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN) interface; Network Service". 

[9] 3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)". 

[10] 3GPP TS 45.001: "Digital cellular telecommunications system (Phase 2+); Physical layer on the 

radio path; General description". 

[11] 3GPP TS 45.002: "Digital cellular telecommunications system (Phase 2+); Multiplexing and 

multiple access on the radio path". 

[12] 3GPP TS 43.002: "Network Architecture". 

[13] 3GPP TS 48.001: "Base Station System - Mobile Services Switching Centre (BSS-MSC) Interface 

General Aspects". 
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[14] 3GPP TS 48.002: "Base Station System - Mobile Services Switching Centre (BSS-MSC) Interface 

- Interface Principles". 

[15] 3GPP TS 48.004: "Base Station System - Mobile Services Switching Centre (BSS-MSC) Interface 

Layer 1 Specification". 

[16] 3GPP TS 48.006: "Signalhng Transport Mechanism Specification for the Base Station System - 

Mobile Services Switching Centre (BSS-MSC) Interface". 

[17] 3GPP TS 48.008: "Mobile Switching Centre - Base Station system (MSC-BSS) Interface Layer 3 

Specification". 

[18] 3GPP TS 48.063: "Inband Tandem Free Operation (TFO) of Speech Codecs; Service Description; 

Stage 3". 

[19] 3GPP TS 25.420: "UTRAN lur Interface: General Aspects and principles". 

[20] 3GPP TS 25.421: "UTRAN lur Interface Layer 1". 

[2 1 ] 3GPP TS 25 .422: "UTRAN lur Interface signalling transport" . 

[22] 3GPP TS 25.423: "UTRAN lur Interface RNSAP signalling". 

[23] 3GPP TS 24.022: "Radio Link Protocol (RLP) for Circuit Switched Bearer and Teleservices". 

[24] 3GPP TS 44.018: "Radio Resource Control Protocol". 

[25] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network Protocols - Stage 

3". 

[26] 3GPP TS 44.060: "Radio Link Control / Medium Access Control (RLC/MAC) protocol". 

[27] 3GPP TS 45.008: "Radio subsystem Link Control". 

[28] 3GPP TS 23.003: "Numbering, Addressing and Identification". 

[29] 3GPP TS 23.221: "Architectural requirements (Release 5)" 

[30] 3GPP TS 23.236: "Intra Domain Connection of RAN Nodes to Multiple CN Nodes" 

[31] 3GPPTS 23.195: "Provision of User Equipment Specific Behaviour Information (UESBI) to 

network entities" 

2.2 Informative references 

[32] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2". 

[33] 3GPP TS 43.64: "General Packet Radio Service (GPRS); Overall description of the GPRS radio 

interface; Stage 2". 

[34] 3GPP TS 23.034: "High Speed Circuit Switched Data (HSCSD); Stage 2". 

[35] 3GPP TS 41.004: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[36] ITU-T Recommendation 1.130: "Method for the characterization of telecommunication services 

supported by an ISDN and network capabilities of an ISDN". 

[37] ITU-T Recommendation Q.65: "The unified functional methodology for the characterization of 

services and network capabilities including alternative object-oriented techniques". 

[38] 3GPP TS 23.153: "Out of Band Transcoder Control" 
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Symbols and abbreviations 



3.1 Symbols 



For the purposes of the present document, the following symbols apply: 



A 

Gb 

lu-cs 

lu-ps 

lur-g 



Interface between a BSS and a 2G MSC 
Interface between a BSS and a 2G SGSN 
Interface between a BSS and a 3G MSC 
Interface between a BSS and a 3G SGSN 
Interface between two BSSs 



NOTE: whether the lur-g interface is also used between a BSS and an RNC is FFS. 

Um Interface between MS and BSS 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. Additional applicable abbreviations can be 
found in 3GPP TS 41.004 [27]and 3GPP TS 43.064 [25]. 

ARQ Automatic Repeat reQuest 

AS Access Stratum 

BCCH Broadcast Control CHannel 

BSS Base Station Subsystem 

CBCH Cell Broadcast CHannel 

CC Call Control 

CN Core Network 

CPBCCH Compact PBCCH 

CS-i GPRS Coding Scheme i 

DC Dedicated Control 

DLC Data Link Control 

DBPSCH Dedicated Basic Physical Sub CHannel 

ECSD Enhanced Circuit Switched Data 

EDGE Enhanced Data rates for Global Evolution 

E-FACCH Enhanced FACCH 

E-IACCH Enhanced Inband Associated Control CHannel 

EGPRS Enhanced GPRS 

EPC Enhanced Power Control 

EPCCH Enhanced Power Control CHannel 

E-TCH Enhanced TCH 

FACCH Fast Associated Control CHannel 

FPC Fast Power Control 

GC General Control 

GERAN Gsm/Edge Radio Access Network 

GPRS General Packet Radio Service 

GRA Geran Registration Area 

G-RNTI Geran Radio Network Temporary Identity 

GSM Global System for Mobile Communications 

IETF Internet Engineering Task Force 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

LCS Location Services 

MAC Medium Access Control 

MCS-i EGPRS Modulation and Coding Scheme i 

MM Mobility Management 

MS Mobile Station 

NAS Non Access Stratum 

NSAPI Network layer SAPI 
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Nt Notification 

O-FACCH Octal FACCH 

O-TCH Octal TCH 

PBCCH Packet BCCH 

PDCH Packet Data CHannel 

PDCP Packet Data Convergence Protocol 

PDP Packet Data Protocol 

PDTCH Packet Data TCH 

PDU Packet Data Unit 

PLMN Public Land Mobile Network 

PTCCH Packet Timing advance Control CHannel 

P-TMSI Packet TMSI 

PUESBINE Provision of UE Specific Behaviour Information to Network Entities 

QoS Quality of Service 

RAB Radio Access Bearer 

RANAP Radio Access Network Application Part 

RB Radio Bearer 

RLC Radio Link Control 

RNSAP Radio Network Subsystem Application Part 

ROHC Robust Header Compression 

RRC Radio Resource Control 

RTP Real Time Protocol 

SACCH Slow Associated Control CHannel 

S ACCH/TP S ACCH for enhanced power control 

SAP Service Access Point 

SAPI Service Access Point Identifier 

SDCCH Stand-alone Dedicated Control CHannel 

SDU Service Data Unit 

SBPSCH Shared Basic Physical Sub CHannel 

TBF Temporary Block Flow 

TCH Traffic Channel 

TCP Transmission Control Protocol 

TLLI Temporary Logical Link Identifier 

TMSI Temporary Mobile Subscriber Identity 

UDP User Datagram Protocol 

UESBI UE Specific Behaviour Information 

UMTS Universal Mobile Telecommunication System 

USE Uplink State Elag 

UTRAN UMTS Terrestrial Radio Access Network 



GERAN Architecture 



4.1 



GERAN Reference Architecture 



The reference architecture of GERAN is illustrated in Figure L 

GERAN connects with 3 interfaces A, Gb and lu interfaces to the core network. Any combination comprising one, two 
or three of these 3 interfaces is possible. Two Base Station Subsystems (BSS) maybe connected to each other with an 
lur-g interface. A BSS and an RNC may also be connected via an lur-g interface. 

The mobile station shall operate using only the following modes: 

a) A/Gb mode, e.g. for pre-Release 5 terminals, for Release 5 terminals when connected to a GERAN with no lu 
interface towards the Core Network; 

b) lu mode (i.e. ly.cs and lu-ps), eg- for Release 5 terminals when connected to a GERAN with !„ interfaces towards 
the Core Network. 

Both modes must be supported by the standard and no other modes (e.g. A / ly.ps or I^.cs / Gb) shall be allowed. 
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MS 



Urn 



MS 



GERAN 



BSS 



BSS 



UTRAN 



lur-g 




Gb 



lu 



lur-g 



RNC 



GSM/UMTS 
Core Network 



Figure 1 : GERAN reference architecture 

The functional split within a BSS is implementation-dependent. 



4.2 UMTS Architecture applied to GERAN 

This clause describes the GERAN architecture when it connects to the core network through an lu interface. Figure 2 
shows the assumed UMTS architecture as outHned in 3GPP TS 23.110. GERAN is showed instead of UTRAN. The 
figure below shows the UMTS architecture in terms of its entities Mobile Station, GERAN and Core Network. The 
respective reference points Um (Radio Interface) and lu (CN-RAN reference) are shown. The figure illustrates 
furthermore the high-level functional grouping into the Access Stratum and the Non- Access Stratum. 

The Access Stratum offers services through the following Service Access Points (SAP) to the Non-Access Stratum: 

- General Control (GC) SAPs; 

- Notification (Nt) SAPs; and 

- Dedicated Control (DC) SAPs. 

The SAPs are marked with circles in Figure 2. 




Radio 
(Um) 



Figure 2: UIVITS Archiitecture applied to GERAN 
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This model can be further refined to distinguish the end AS entities, which provide the services to higher layers, from 
the local entities, which provide services over respectively the Um and the lu reference point. Figure 3 presents the 
refined model. 




444= 



Relay 



4'4°4 444= 



Um Stratum 




44°4 



lu Stratum 



MS 



GERAN 



Radio 
(Um) 



Core Network 



lu 



Figure 3: Assumed GERAN Model 



4.3 



Protocol architecture in PS domain 



4.3.1 General 

Specifications and more detailed descriptions of the lu-ps interface protocols and architecture can be found in [1-6]. 
Specifications and more detailed descriptions of the Gb interface protocols and architecture can be found in [7-9]. 
The Um interface protocols are described in clauses 5 and 6. 



4.3.2 User plane 



Figure 4 shows the user plane for GERAN connected to a packet switched core network domain. For reference, GPRS 
and UMTS protocol stacks when connected to the packet switched core network domain are described in 3GPP TS 
23.060 [24]. 
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Ack/Unack 
RLC 



MS 



RLC 



MAC 



GERAN 



PDCP 



...Re.ray.... 



BSSGP 



Network 
Service 
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RLC 



MAC 



Urn 

H !— ► 



GTP-U 

UDP/IP 

As defined in 
lu Specs. 

L2 



SGSN 



SNDCP 



Gb 
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UDP/IP 

As defined in 
lu Specs. 

L2 



Network 
Service 



Common protocols 
lu influenced protocols 
Gb influenced protocols 



Figure 4: User Plane protocols towards Packet Switched Core Network domain 

The lu-ps protocol stack is inherited from UMTS specifications (Ref. 1-6). However, GERAN expects more transport 
layer options than ATM (3GPP Work Item "IP Transport in UTRAN"). 

4.3.3 Control plane 

Figure 5 shows a high level view of the control plane for GERAN when connected to a packet switched core network 
domain. For reference, GPRS and UMTS Control Plane protocol stacks when connected to the packet switched core 
network domain are depicted in Figures 7 of [24] and 8 of [24] respectively. 



MS 



GERAN 



SGSN 



GMM/SM 



LLC 



Ack/Unack 
RLC 



MAC 



LAPDrr LAPDm 



Relay - 



Ack/Unack 
RLC 



MAC 



UlTl 



BSSGP 



Network 
Service 



^ 



RANAP 



SCCP 

As Defined 
in lu Specs. 

L3 



GMM/SM 



Gb 



lu-ps 



RANAP 

SCCP 

As Defined 
in lu Specs. 

L3 



LLC 



BSSGP 



Networl< 
Service 



Common protocols 
lu influenced protocols 
Gb influenced protocols 



Figure 5: Control Plane protocols towards Packet Switched Core Network domain 

NOTE: The lu-ps protocol stack is inherited from UMTS specifications (Ref. 1-6). However, GERAN expects 
more transport layer options than ATM (3GPP Work Item "IP Transport in UTRAN"). 

NOTE: RRC uses the services of LAPDm only on broadcast control channels. 
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4.4 



Protocol architecture in CS domain 



4.4.1 General 

Specifications and more detailed descriptions of the lu-cs interface protocols and architecture can be found in [1-6.]. 

Specifications and more detailed descriptions of the A interface protocols and architecture can be found in [13-18]. 
The RLP Protocol is found in [23]. 

The Um interface protocols are described in clauses 5 and 6. 

Within GERAN, speech and data frames will be transmitted at the radio interface using a specific channel coding. As 
the support of transceivers with limited capabilities has to be assured, the capabilities provided by the GERAN have to 
be taken into account by the CN during call set-up and Relocation. Additionally, in case a RAB has to be established or 
relocated for CS services, it is required that the GERAN BSC receives specific information from the MSC-Server. 



4.4.2 User plane 



Figure 6 shows the user plane for GERAN connected to a circuit switched core network domain 
MS ; GERAN 3G-MSC 
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Figure 6: User Plane protocols towards Circuit-Switched Core Network domain 

NOTE: The figure only shows existing Release 99 Transport layer options for A and lu-cs. 

NOTE: The lu-cs protocol stack is inherited from UMTS specifications [1-6]. However, GERAN expects more 
transport layer options than ATM (3GPP Work Item "IP Transport in UTRAN"). 



4.4.3 Control plane 



Figure 7 shows the control plane for GERAN connected to a circuit switched core network domain. 
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Figure 7: Control Plane Protocols towards Circuit-Switched Core Network Domain 

NOTE: The lu-cs protocol stack is inherited from UMTS specifications [1-6]. However, GERAN expects more 
transport layer options than ATM (3GPP Work Item "IP Transport in UTRAN"). 

NOTE: RRC uses the services of LAPDm only on broadcast control channels. 

4.5 lur-g interface 
4.5.1 General principles 

The support of the lur-g interface in GERAN is optional. It should be noted however that this allows for registration 
areas to span across several BSS (and possibly RNS) areas. Registration areas may refer to GRAs or URAs. 

The general principles for the specification of the lur-g interface are as follows: 

- the lur-g interface should be open; 

- the use of the lur-g interface may be used for Mobile Stations operating in lu mode but not for Mobile 
Stations operating in A/Gh mode; 

- the lur-g interface shall support the exchange of signaling information between two BSSs, or between a 
BSS and an RNC; 

- from a logical standpoint, the lur-g is a point to point interface between two BSSs or between a BSS and an 
RNC. A point to point logical interface should be feasible even in the absence of a physical direct 
connection between the two entities; 

- the behaviour of the MS shall be independent of the presence of the lur-g interface or of the presence of 
any of its planes. 

When specifying the lur-g interface, it is deemed necessary to introduce a separation between the Radio Network 
functionality and the Transport Network functionality to facilitate introduction of future technology (see Figure 8). 
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Figure 8: Separation of Radio Networl< Protocols and transport over the lur-g interface 

4.5.2 Protocol architecture 

Figure 9 represents the protocol architecture for lur-g interface. It is based on the UTRAN lur protocol architecture, 
where only the control plane of the protocol is used for lur-g. See [19-22]. 

The Radio Network Subsystem Application Part (RNSAP) for GERAN contains a sub-set of the UTRAN RNSAP 
procedures. However the contents of the messages used over lur-g might differ. 

NOTE: The Transport Network protocols shown here are adopted from UTRAN Release 99, although they are 
subject to change for GERAN Release 5 and this figure will be modified accordingly. 
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Figure 9: lur-g Protocol Architecture 



4.5.3 RNSAP protocol 



The protocol responsible for providing signaling information across the lur-g interface is called the Radio Network 
Subsystem Application Part (RNSAP). The RNSAP is terminated by the two BSSs or the BSS and the RNC inter- 
connected via the lur-g interface RNSAP Procedure Modules. 
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RNSAP procedures as defined in UTRAN are divided into four modules as follows: 

1 . RNSAP Basic Mobility Procedures; 

2. RNSAP DCH Procedures; 

3. RNSAP Common Transport Channel Procedures; 

4. RNSAP Global Procedures. 

In case of GERAN lur-g, only RNSAP Basic Mobility Procedures and RNSAP Global Procedures are adopted from 
UTRAN and modified as necessary. Table 1 lists elementary procedures that are used with RNSAP in lur-g interface. 
These are Class 2 procedures that do not require response and are always considered successful. 

The Basic Mobility Procedures module contains procedures used to handle the mobility within GERAN, while the 
Global Procedures module contains procedures that are not related to a specific MS. 

Table 1 : Elementary Procedures 



Elementary Procedure 


Initiating Message 


Uplink Signaling Transfer 


UPLINK SIGNALLING TRANSFER 
INDICATION 


Downlink Signaling Transfer 


DOWNLINK SIGNALLING 
TRANSFER REQUEST 


SRNS Relocation Commit 


SRNS RELOCATION COMMIT 


Paging 


PAGING REOUEST 


Error Indication 


ERROR INDICATION 



4.6 Support for MSC/SGSN in pool 

The stage 2 description on how the MSC/SGSN in pool concept is supported in the BSS and MS in GERAN lu mode is 
described in [30]. 

4.7 CS services for GERAN lu-mode 

Call Set-up: 

In case of a call set-up towards the CS domain, the BSC shall provide GERAN specific capabilities in the "GERAN 
Classmark" within the INITIAL UE MESSAGE to the MSC-Server of the serving cell that have to be taken into 
account by the MSC-Server during call set-up (e.g. to negotiate a speech codec [38]). 

To be able to set-up an appropriate RB with the corresponding channel coding for a CS service, the BSC will receive 
specific information within the "GERAN BSC Container" from the MSC-Server within the RAB ASSIGNMENT 
REQUEST message. 

In case the MS moves to a new cell during the period between the transmission of the INITIAL UE MESSAGE and the 
reception of the RAB ASSIGNMENT REQUEST message, the RAB Assignment may fail, as the BSC may not be able 
to set-up the requested RB, because different capabilities are provided in that new cell. In this case the BSC shall report 
the unsuccessful RAB establishment to the CN by indicating an appropriate cause value within the RAB 
ASSIGNMENT RESPONSE message and shall include the "GERAN Classmark" of the new cell. Based on the 
received "GERAN Classmark" the MSC-Server may re-attempt the RAB Assignment procedure. 

Relocation: 

In case the whole RAN provides the same capabilities with regard to CS services, the exchange of the "GERAN 
Classmark" between RAN and CN is not required during the Relocation procedure. 

In case the whole RAN does not provide the same capabilities with regard to CS services, the exchange of the "GERAN 
Classmark" between RAN and CN is required during the Relocation procedure to avoid that the CN has to store cell 
related information and to be able to reuse the existing Relocation procedure inside the CN. The exchange of the 
"GERAN Classmark" shall be performed as follows: In case of Relocation to GERAN lu-mode, the Source RAN-node 
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shall transfer the "GERAN Classmark" of the GERAN target cell to the MSC-Server within the RELOCATION 
REQUIRED message, which has to be taken into account by the CN during the execution of the Relocation procedure. 

To be able to set-up an appropriate RB with the corresponding channel coding in the target cell for a CS service, the 
Target BSC will receive the requested specific information within the "GERAN BSC Container" from the MSC-Server 
within the RELOCATION REQUEST message. 

In case the target BSC cannot allocate radio resources corresponding to the "GERAN BSC Container" content, received 
within the RELOCATION REQUEST message, the BSC shall report this failure event by including an appropriate 
cause value within the RELOCATION FAILURE message to the MSC-Server. In this case the target BSC shall 
additionally include the "GERAN Classmark" of the target cell in the RELOCATION FAILURE message sent to the 
MSC-Server. If the MSC-Server receives a RELOCATION FAILURE message indicating "GERAN lu-mode failure", 
the MSC-Server shall report this relocation failure to the source RAN node. Optionally, if the received "GERAN 
Classmark" shows that the requested CS service is incompatible with the transceiver capabilities of the target cell, the 
MSC-Server may initiate a second handover attempt towards the target BSC taking the received "GERAN Classmark" 
into account. 

4.8 User Equipment Specific Behaviour Information (UESBI) in 
GERAN lu mode 

The Provision of User Equipment Specific Behaviour Information to network entities (PUESBINE) feature is described 
in 3GPP TS 23.195 [31]. The PUESBINE feature is supported in GERAN lu mode as in UTRAN and in GERAN, it is 
applicable only to the UMTS functionality and GERAN to UTRAN handovers. 



5 Radio Interface Protocol Architecture 

The radio interface protocol architetcture when GERAN connects to A or Gb interface is the same as defined in earlier 
releases. The clause below describes the protocol architecture when connecting through an lu interface to the CN. 
Whether the protocol structure described in this clause (5) is also applicable for an evolved A interface is for further 
study. The multiplexing principles of data coming from the different CN interfaces (A, Gb and lu) are illustrated in 
clause 5.3. 

5.1 Protocol Structure when connecting through lu 

The radio interface is layered into three protocol layers: 

the physical layer (LI); 

the data link layer (L2); 

the network layer (L3). 

Layer 2 is split into the following sublayers: Radio Link Control (RLC), Medium Access Control (MAC) protocol and 
Packet Data Convergence Protocol (PDCP). RLC/MAC is used as layer 2 in the control plane below RRC, except for 
operation on the BCCH, where DL is used. Whether the Broadcast/Multicast Control (BMC) protocol described in 
25.301 is needed is for further study. 

The protocol architecture is divided into Control (C-) and User (U-) planes. The RLC and MAC protocols and the 
physical layer carries data from both C- and U-plane. PDCP exists in the U-plane only. 

In the C-plane, Layer 3 is partitioned into sublayers where the lowest sublayer, denoted as Radio Resource Control 
(RRC), interfaces with layer 2 and terminates in the GERAN. The next sublayer provides 'Duplication avoidance' 
functionality as specified in 3GPP TS 24.007. It terminates in the CN but is part of the Access Stratum; it provides the 
Access Stratum Services to higher layers. The higher layer signalling such as Mobility Management (MM) and Call 
Control (CC) are assumed to belong to the non-access stratum, and therefore not in the scope of 3GPP TSG GERAN. 
On the general level, the protocol architecture is similar to the current ITU-R protocol architecture, ITU-R M.1035. 

Figure 10 shows the radio interface protocol architecture. Each block in Figure 10 represents an instance of the 
respective protocol. Service Access Points (SAP) for peer-to-peer communication are marked with circles at the 
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interface between sublayers. The SAP between MAC and the physical layer provides the logical channels. In the 
C-plane, the interface between 'Duplication avoidance' and higher L3 sublayers (CC, MM) is defined by the General 
Control (GC), Notification (Nt) and Dedicated Control (DC) SAPs. A description of these SAPs can be found in 3GPP 

TS 23.110. 

Also shown in the figure are connections between RRC and MAC as well as RRC and LI providing local inter-layer 
control services. An equivalent control interface exists between RRC and the RLC sublayer, between RRC and the 
PDCP sublayer. These interfaces allow the RRC to control the configuration of the lower layers. For this purpose 
separate Control SAPs are defined between RRC and each lower layer (PDCP, RLC, MAC, and LI). 

The GERAN can be requested by the CN to prevent loss of data according to the quality of service requirements 
[UMTS 23.107] of the bearer in question (i.e. independently of the handovers on the radio interface), as long as an 
inter-BSS handover does not take place. This is a basic requirement to be fulfilled by the GERAN retransmission 
functionality as provided by the RLC sublayer. However, in case of the inter-BSS handover, the prevention of the loss 
of data may not be guaranteed autonomously by the GERAN but relies on 'Duplication avoidance' functions in the CN. 



C-plane signalling 
GCJ-^ Nt, ^DC, 



U-plane information 




Figure 10: Radio Interface protocol architecture 

Figure 10 reflects the radio interface protocol architecture as defined specifically in Release 5 connecting to the lu 
interface. 
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5.2 Multiplexing Principles 

5.2.1 IVIultiplexing of different types of radio access bearers for one IVIS 

GERAN can allocate multiple dedicated and shared basic physical subchannels to a mobile station. The allocation shall 
be consistent with the mobile station's capability (See GSM 05.02 [11]). 

Different types of Radio Access Bearer Services can be multiplexed for one MS using functionality of the MAC and/or 
the physical layers on one or more shared and/or dedicated basic physical subchannels. One radio bearer can only be 
mapped either on dedicated or shared basic physical subchannels. 

5.2.2 IVIultiplexing of user plane data from different core network interfaces 

Figure 1 1 shows the multiplexing principles on the network side of user plane data coming from different type of core 
network interfaces. User data from the lu interface and user data from the Gb interface are multiplexed on MAC level, 
through shared basic physical subchannels, or on the physical layer, through different basic physical subchannels. User 
data coming from the A interface is multiplexed with user data from the Gb interface and user data from the lu interface 
on the physical layer through different basic physical subchannels. 




Figure 1 1 : Multiplexing principles on the network side of user plane data flows coming 

from different interfaces 
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5.3 lu vs A/Gb mode selection 

5.3.1 Introduction 

A GERAN cell can support either A/Gb mode only, or lu mode only, or both modes. The support of each mode depends 
on the interfaces via which the GERAN is connected to the Core Network nodes. 

The support of each mode of operation by a GERAN cell is indicated in the broadcast system information messages, see 
subclause 6.3.1. 

Similarly, the mode(s) of operation a mobile station supports is indicated in information concerning radio aspects of the 
mobile station, made available to the radio access network, see [25]. lu mode support may also be indicated implicitly at 
radio access by the mobile station. A mobile station can only operate either in A/Gb mode or in lu mode at a given time. 

5.3.2 PLIVIN, cell and mode (re-)selection in GERAN 

The procedures for PLMN selection apply independently of the mode(s) supported by the cells belonging to the 
available PLMNs. 

The procedures for cell re-selection defined in A/Gb mode apply also in lu mode. The cell re-selection may be under the 
control of the network or the mobile station, see [26]. 

In case cell re-selection is under control of the mobile station, cell re-selection shall only be based on radio criteria and 
not on which mode is supported by the neighbour cells, see [27]. The lu mode shall be selected in the target cell if 
supported by both the cell and the mobile station unless otherwise ordered by the network. 

NOTE: The above text outlines the default mechanism of mode of operation selection and does not prohibit the 
introduction of a more flexible solution, which avoids unnecessary mode of operation changes, at a later 
stage. 

In case cell re-selection is under control of the network, the mode to apply in the target cell is provided by the network. 

NOTE: When a mobile station is allocated dedicated physical sub-channels, the maintenance of the radio resources is 
handled via handover procedures by the network. Irrespective of the mode of operation in the current cell, the 
network will select the mode of operation to apply in the target cell. 

Once the mode of operation has been chosen in the new cell, the relevant procedures to A/Gb or lu mode apply. 
Procedures will be defined in A/Gb or lu mode to allow for changing mode without changing cell. 



6 User and Control Plane Protocols 

This clause provides an overview on the user and control plane protocols of GERAN. For detailed description of each 
of the layer, please refer to the corresponding specification (see below). 

6.1 Identifiers in GERAN 

The identities listed below shall be used for an MS connected, via GERAN through an lu interface, to the CN. The 
identities for an MS connected, via GERAN through a Gb interface, to the CN are defined in Release 99 and can be 
found in 3GPPTS 23.060. 

6.1.1 IMSI, TMSI and P-TMSI 

The International Mobile Subscriber Identity (IMSI), Temporary Mobile Subscriber Identity (TMSI) and Packet 
Temporary Mobile Subscriber Identity (P-TMSI) are defined in 3GPP TS 23.003. 
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6.1.2 G-RNTI 

A GERAN Radio Network Temporary Identity (G-RNTI) shall be allocated to a mobile station by the BSS when an 
RRC connection is established between this mobile station and the GERAN. It identifies the MS within GERAN and 
may be used the same way TLLI is currently used over the radio interface in (E)GPRS (A/Gb mode). The G-RNTI is 
defined in 3GPP TS 44.118. It is 32 bits in length and contains the serving BSC identity (SBSC-id) and the MS identity 
(S-RNTI) which is unique within the area of its serving BSC. 

6.1.3 NSAPI, RABID and RB ID 

The UMTS definitions and mapping amongst NSAPI, RAB ID and RB ID shall be used for GERAN 3GPP TS 23.060. 

The Network layer Service Access Point Identifier (NSAPI) and IMSI are used for network layer routing. In the MS, 
NSAPI identifies the PDP-SAP. In the SGSN and GGSN, NSAPI identifies the PDP context associated with an MM 
context. 

In communication with BSS across the lu-ps and Um interfaces, the RAB ID is used to identify the radio access bearer 
and shall be identical to the NSAPI value. In the BSS, the RAB ID identifies the BSS RAB context. The RAB ID shall 
uniquely identify the RAB for a specific CN domain and a particular MS. 

GERAN establishes exactly one radio bearer to realize each RAB. Within the MS and the GERAN, the RB ID shall 
uniquely identify the radio bearer for a particular MS. 

6.1.4 RBId, RRBId, andTFI 

An RB Id (Radio Bearer Identity) identifies an RB (Radio Bearer). An RB Id has one of 32 possible values. Signalling 
radio bearers use RB Ids to 4; user radio bearers use the rest. RB Ids are assigned at RB establishment and remain 
assigned until the radio bearer or the RRC connection is released. 

An RRB Id (Reduced Radio Bearer Identity) identifies a TBF on FACCH, SACCH, or SDCCH. An RRB Id has one of 
8 possible values. For such TBFs carrying SRBs, RRB Ids are implicitly assigned when the DBPSCH is assigned. For 
such TBFs carrying URBs, the mapping between RB Id and RRB Id is given at RB setup. 

A TFI (Temporary Flow Identity) identifies a TBF (Temporary Block Flow) on PDTCHs. A TFI has one of 32 possible 
values. For SBPSCHs, when a TBF is established, one unique TFI is assigned accross all SBPSCHs that carry the TBF. 
Uplink and downlink TFIs are independent, i.e., assignment of a TFI in one direction does not constrain the TFI used in 
the other direction. The GERAN establishes the association between RB Id and TFI when the TBF is established. For 
DBPSCHs, TFIs are implicitly assigned to TBFs when the corresponding RB is allocated on the DBPSCH, and remain 
assigned until the RB is deallocated from the DBPSCH. For each RB on a DBPSCH, the TFI equals the RB Id. 

A TBF on one or more TCHs is the only user of the TCHs; hence, no specific MAC-layer identifier is needed. 

6.1.5 USF 

For a TBF on one or more PDTCHs, USF (Uplink State Flag) is sent in the downlink and identifies which TBF may use 
the next block (or blocks) on the uplink SBPSCH or DBPSCH. A USF has one of 8 values. 

A unique USF is assigned per timeslot for the duration of the TBF. The GERAN establishes the association between 
TFI and USFs when the TBF is established. 

6.1.6 SAI 

The SAI (Service Area Identifier) identifies a Service Area that consists of one or more GERAN and UTRAN cells. It is 
defined in [25]. The SAI is unique within the PLMN. The SAI is used over the lu interface for mechanism such as inter- 
system handover, location services, charging etc. 

The SAI is constructed as follows: 

SAI = MCC + MNC + LAC + SAC 
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6.1.7 BSC-id 

Each BSC that supports the lu interface will be allocated a BSC-id (Base Station Control Identifier). The BSC-id is 
constructed the same way as the RNC-id, which is defined in [25]. The BSC-id and the RNC-id are allocated from the 
same addressing space and are unique within the PLMN. The BSC-id together with the PLMN-id is used for addressing 
BSCs over the lur-g and the lu interface. 

6.1 .8 LAI for 3G core network 

For the case the network does not support common Location Areas for the 2G and 3G CNs, a GERAN cell that supports 
lu mode of operation needs to support an additional Location Area Identity (LAI) for the 3G CN [25] [26]. For the case 
the network supports common Location Areas for the 2G and 3G CN, a GERAN cell supporting both A/Gb and lu 
modes of operation may not need an additional LAC for the 3G CN. The LAI is unique within the PLMN. 

The LAI is constructed as follows: 

LAI = MCC + MNC + LAC 

NOTE: It is FFS whether the full LAC for the 3G CN needs to be broadcast in the cell. It might be possible to 
share part of it with the LAC for the 2G CN. 

6.1 .9 RAI for the 3G core network 

For the case the network does not support common Routing Areas for the 2G and 3G CN, a GERAN cell that supports 
lu mode of operation needs to support an additional Routing Area Identity for the 3G [25] [26]. For the case the 
network supports common Routing Areas for the 2G and 3G CN, a GERAN cell supporting both A/Gb and lu modes of 
operation may not need an additional RAC for the 3G CN. The RAI is unique within the LAI. 

The RAI is constructed as follows: 

RAI = LAI + RAC 

NOTE: It is FFS whether the full RAC for the 3G CN needs to be broadcast in the cell. It might be possible to 
share part of it with the RAC for the 2G CN. 



6.1.10 GRA Identity 



A GERAN Registration Area (GRA) is identified by the GRA Identity. GRAs consist of one or more cells and are 
allowed to overlap as well as to overlap BSCs/RNCs and LAs/RAs. One or more GRA Identities are broadcast in the 
cell. 

6.1 .1 1 GERAN internal Cell Identity 

A GERAN cell identity (GC-id) will be used to address cells in GERAN. The GC-id consists of the BSC-id identifying 
the BSC controlling the cell and a cell identity CI unique within that BSC. The same CI is used to address the cell for 
both A/Gb mode and lu mode. 

NOTE: In GERAN A/Gb mode, the CI is unique within the Location Area and in GERAN lu mode, the CI needs 
to be unique within the BSC Area. 

6.2 Relay 

The relay function of GERAN functionality and whether some functions need to be standardized are FFS. 

6.3 Radio Resource Control (RRC) 

RRC is a layer 3 control plane protocol for radio resource management. 
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6.3.1 RRC Functions 

The Radio Resource Control (RRC) layer handles the control plane signalling of Layer 3 between the MSs and the 
GERAN. The RRC performs the following functions: 

Broadcast of information provided by the non-access stratum (Core Network): The RRC layer performs 
system information broadcasting from the network to all MSs. The system information is normally repeated on 
a regular basis. The RRC layer performs the scheduling, segmentation and repetition when such broadcasting is 
carried on BCCH. This function supports broadcast of higher layer (above RRC) information. This information 
may be cell specific or not. As an example RRC may broadcast Core Network location service area information 
related to some specific cells. 

Broadcast of information related to the access stratum (GERAN): The RRC layer performs system 
information broadcasting from the network to all MSs. The system information is normally repeated on a 
regular basis. The RRC layer performs the scheduling, segmentation and repetition when such broadcasting is 
carried on BCCH. This function supports broadcast of typically cell-specific information. 

Establishment, re-establishment, maintenance and release of an RRC connection between the MS and the 

GERAN: The establishment of an RRC connection is initiated by a request from higher layers at the MS side to 
establish the first Signalling Connection for the MS. The establishment of an RRC connection includes an 
optional cell re-selection, an admission control, and a layer 2 signalling link establishment. The release of an 
RRC connection can be initiated by a request from higher layers to release the last Signalling Connection for 
the MS or by the RRC layer itself in case of RRC connection failure. In case of connection loss, the MS 
requests re-establishment of the RRC connection. In case of RRC connection failure, RRC releases resources 
associated with the RRC connection. 

Establishment, reconfiguration and release of Radio Bearers: The RRC layer can, on request from higher 
layers, perform the establishment, reconfiguration and release of Radio Bearers in the user plane. A number of 
Radio Bearers can be established to an MS at the same time. At establishment and reconfiguration, the RRC 
layer performs admission control and selects parameters describing the Radio Bearer processing in layer 2 and 
layer 1, based on information from higher layers. 

Assignment, reconfiguration and release of radio resources for the RRC connection: Depending on the 
RRC and MAC states, the RRC layer may handle the assignment of radio resources needed for the RRC 
connection including needs from both the control and user planes. The RRC layer may reconfigure radio 
resources during an established RRC connection. RRC indicates to the MS resource allocations for purposes of 
inter system handovers. 

RRC connection mobility functions: The RRC layer performs evaluation, decision and execution related to 
RRC connection mobility during an established RRC connection, such as handover, preparation of handover to 
UTRAN or other systems, cell re-selection and cell/GRA update procedures, based on e.g. measurements done 
by the MS. 

Release of signalling connections: The RRC layer provides the necessary functions for the GERAN or the MS 
to request the release of a signalling connection. 

Paging/notification: The RRC layer can broadcast paging information from the network to selected MSs on 
PCCCH making use of the MAC layer services. Higher layers on the network side can request paging and 
notification. The RRC layer can also initiate paging during an established RRC connection. 

- Listening to BCCH: The RRC layer may need to listen to the BCCH of the serving cell for working out 
whether lu mode is supported in this cell. The RRC layer listens to the BCCH of neighbouring cells for 
neighbour cell measurements; the RRC layer also receives paging information on the PCCCH. 

Routing of higher layer PDUs: This function performs at the MS side routing of higher layer PDUs to the 
correct higher layer entity, at the GERAN side to the correct RANAP entity. 

Control of requested QoS: This function shall ensure that the QoS requested for the Radio Bearers can be met. 
This includes the allocation of a sufficient number of radio resources. 

MS measurement reporting and control of the reporting: The measurements performed by the MS are 
controlled by the RRC layer including both GSM/EDGE air interface and other systems. The RRC layer is 
responsible for sending information that control the MS measurement reporting when using the S ACCH 
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channel. The RRC layer also performs the reporting of the measurements from the MS to the network using 
SACCH. 

Power control: The RRC layer controls parameters for normal power control, enhanced power control and fast 
power control. 

Control of ciphering: The RRC layer provides procedures for setting of ciphering (on/off) between the MS and 
GERAN. 

Integrity protection: This function controls integrity protection and performs integrity protection those RRC 
messages that are considered sensitive and/or contain sensitive information. 

Support for Location Services. Signaling between MS and GERAN to support positioning of an MS. 

Timing advance control. The RRC controls the operation of timing advance on dedicated basic physical 
subchannels. 

6.3.2 RRC Connection Levels 

The different levels of RRC connection between MS and GERAN are listed below: 

No signalling connection exists 

The MS has no relation to GERAN, only to CN. For data transfer, a signalling connection has to be established. 

A signalling connection exists 

There is an RRC connection between the MS and GERAN. The MS position can be known on different levels: 

- GERAN Registration Area (GRA) level 

The MS's position is known on GERAN registration area level. GRA is a specified set of cells, which can be 
identified in the PBCCH. 

- Cell level 

The MS's position is known on cell level. 

6.3.3 RRC Connection Modes 

Two modes of operation are currently defined for the MS, RRC -Idle mode and RRC-Connected mode. 

After power on, the MS in RRC -Idle mode may transmit a request to establish an RRC connection with the GERAN. In 
RRC-Idle mode the MS is identified by non-access stratum identities such as IMSI, TMSI and P-TMSI. In addition, the 
GERAN has no own information about the individual MSs in RRC-Idle mode, and can only address e.g. all MSs in a 
cell or all MSs monitoring a specific paging occasion. 

The RRC-Connected mode is entered when the RRC connection is established between the MS and the GERAN. The 
MS is assigned a radio network temporary identity (G-RNTI) to be used as MS identity. MS is identified within a 
GERAN with the G-RNTI. 

Three states are defined in RRC-Connected mode: RRC-Cell_Shared state, RRC-Cell_Dedicated state and RRC- 
GRA_PCH state. 

In RRC-Cell_Shared state, no dedicated basic physical subchannel is allocated to the MS and the position of the MS 
is known by GERAN on cell level; 

In RRC-Cell_Dedicated state, the MS is assigned one or more dedicated basic physical subchannels in the uplink 
and downlink, which it can use anytime. Furthermore, the MS may be assigned one or more shared basic physical 
subchannels. The position of the MS is known by GERAN on cell level. 

In RRC-GRA_PCH state, no basic physical subchannel is allocated to the MS. No uplink activity is possible. The 
location of the MS is known on GERAN Registration area level. 

The behaviour of the MS in each of these states is defined in 3GPP TS 44. 118. 

The MS leaves the RRC -connected mode and returns to RRC -idle mode when the RRC connection is released or at 
RRC connection failure. 
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6.3.4 RRC Connection Mobility 

6.3.4.1 RRC Connection mobility in RRC-ldle mode 

When the mobile station is in RRC-ldle mode, the CN knows the location of the mobile station at RA or LA level 
depending on the CN domain. There is no knowledge of the MS location within the BSS and paging is required to 
trigger an RRC connection establishment prior to any transfer with the MS. Such establishment moves the MS to RRC- 
Connected mode. 

6.3.4.2 RRC Connection mobility in RRC-Connected mode 

Handover procedures are used by the GERAN to control the mobility of the mobile station in RRC-Cell_Dedicated 
state. Such procedures are used to completely modify the channels allocated to the mobile station, e.g. when the cell is 
changed. 

The GERAN is in charge of tracking the location of the mobile station, at cell or GRA level, when in RRC-Cell_Shared 
state or RRC-GRA_PCH state respectively. In such case, the CN to which a signalling connection is established knows 
the location of the mobile station at the BSS level. Cell Update and GRA update procedures are defined to let the 
serving BSS know about any cell or GRA change. 

Cell reselection to a new cell or new GRA may involve signalling exchanges between the mobile station and the source 
BSS through the lur-g interface, depending on the mobile station's RRC state. A Serving BSS relocation may then be 
triggered by the source BSS. 

Upon cell update, serving BSS relocation is triggered. Upon GRA update, it is an implementation issue whether to 
trigger a serving BSS relocation or not. 

A cell can belong to several GRAs. 

It is FES whether RRAs may also be defined. An RRA could cover both GERAN and UTRAN cells. Cell/RRA updates 
may then not be triggered though the MS is moving from a GERAN/UTRAN cell to a UTRAN/GERAN cell. 

6.3.5 RRC protocol and messages 

The RRC protocol and the related RRC messages are defined in [24]. 

Service Areas are defined in GERAN. RRC procedures are identified by RRC Transaction Identifiers. 

The procedures for inter-RAT cell change order between UTRAN and GERAN A/Gb mode are re-used when a cell 
change is ordered from/to a UTRAN cell to/from a GERAN cell in lu mode. 

The procedures for inter-RAT handover between UTRAN and GERAN A/Gb mode are re-used for inter-mode handover 
between GERAN lu mode and GERAN A/Gb mode. Further consideration is however required to assess whether 
procedures for handover within GERAN A/Gb mode can be re-used. 

6.3.6 Support of Radio Bearers in GERAN 

The RRC layer is responsible for setting up radio bearers in the U-plane and the C-plane. 

User Plane Radio Bearers are set-up when a Radio Access Bearer is required to be set-up by the Core Network. 

Control Plane Radio Bearers are established when an RRC connection is set-up by a Mobile Station. Those comprise a 
set of five Signalling Radio Bearers: 

RB is using DLC (as in Fig 10 of 43.051) and shall be used for all messages sent on the BCCH. 

RB 1 shall be used for all messages sent using RLC unacknowledged mode (RLC-UM). 

RB 2 shall be used for all messages sent using RLC acknowledged mode (RLC-AM), except for the RRC messages 
carrying higher layer (NAS) signalling. 

RB 3 and optionally RB 4 shall be used for all RRC messages carrying higher layer (NAS) signalling and sent 
using RLC acknowledged mode (RLC-AM). 
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Association of RBs 1 to 4 and logical channels is provided by the MAC protocol. 

6.4 Packet Data Convergence Protocol (PDCP) 

This clause provides an overview on services and functions provided by the Packet Data Convergence Protocol (PDCP). 
A detailed description of the PDCP is given in 3GPP TS 25.323. 

6.4.1 Services provided to upper layers 

The following services are provided by PDCP to upper layers: 

- PDCP SDU delivery. 

6.4.2 Services expected from RLC layer 

Data transfer in acknowledged mode. 
Data transfer in unacknowledged mode. 
Data transfer in transparent mode. 
Segmentation and reassembly. 
In-Sequence delivery. 

6.4.3 PDCP Functions 

For clarity reason, two PDCP modes are defined in the present document: transparent and non-transparent. The 
transparent and non-transparent modes relate respectively to the PDCP-no-header PDU and the PDCP -data PDU cases 
described in 3GPP TS 25.323. 

The functions performed by the PDCP are dependent on the PDCP mode used. 

6.4.3.1 Transparent Mode 

The name "transparent" means that the PDCP layer does not change the incoming service data units (SDU), i.e. no 
header is added and possible TCP/IP or RTP/UDP/IP headers in the data are left untouched. 

The functions of the transparent mode of PDCP are: 

- Transfer of user data; 

- Relocation of PDCP buffer; 

- PDCP SDU buffering. 

6.4.3.2 Non-Transparent Mode 

The functions of the non-transparent mode of PDCP are: 

- Header adaptation of the IP data streams; 

- Transfer of user data; 

- PDCP SDU buffering; 

- Relocation support appropriate to applicable QoS requirements; 

- If adopted for UTRAN, multiplexing of radio bearers onto RLC entities. 
Different header adaptation mechanisms may be used by the PDCP: 
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Header compression: Transport and network level headers (e.g. RTP/UDP/IP) are compressed in such a way 
that the decompressed headers are semantically identical to the original uncompressed headers. The IETF ROHC 
WG is responsible for standardising header compression schemes. Header compression is suited for standard 
internet applications that are not designed to work only with GERAN and especially for multimedia applications 
therefore the scheme will be used with generic realtime multimedia bearers. 

Header removal: Transport and network level headers (e.g. RTP/UDP/IP) are completely removed. Based on 
information submitted at call setup and based on information derived from lower layer (link & physical), the 
receiving entity can regenerate the headers. The primary application of header removal is the optimized speech 
bearer, and the regenerated header may not always be semantically identical to the original header. 

No header adaptation: Transport and network-level headers (e.g. RTP/UDP/IP) are forwarded. 



6.5 Radio Link Control (RLC) 



This clause provides an overview on services and functions provided by the Radio Link Control (RLC). A detailed 
description of the RLC is given in 3GPP TS 44.060 and 3GPP TS 44.160. 

6.5.1 Services provided to upper layer 

Transparent data transfer. This service transmits higher layer PDUs without altering them nor adding any 
RLC protocol information. 

Acknowledged data transfer. This service transmits higher layer PDUs and guarantees delivery to the peer 
entity. 

Unacknowledged data transfer. This service transmits higher layer PDUs without guaranteeing delivery to the 
peer entity. 

Notification of unrecoverable errors. RLC notifies the upper layer of errors that cannot be resolved by RLC 
itself by normal exception handling procedures. 

- Notification of discard. RLC notifies the upper layer of the higher layer PDUs (RLC SDUs) it discards. 

A local suspend/resume function (FFS): RLC operation may be suspended/resumed if requested by RRC. This 
service is used when the ciphering parameters need to be changed. 

A stop/continue function (FFS): RLC operation may be stopped/continued if requested by RRC. This service is 
used at Serving BSS relocation in order to synchronise the PDCP entities in the MS and ESS to realise a loss- 
less relocation. 

- A reset function (FFS) 

There is a single Radio Bearer per RLC instance. 

6.5.2 RLC Functions 

6.5.2.1 Transparent Mode 

RLC has no functionality when operating in transparent mode. The incoming SDUs are transferred to the MAC layer 
without being altered. No upper layer protocol information is removed. No RLC protocol information is added. All 
necessary signalling is made out of band. 

6.5.2.2 Non-Transparent Mode 

In non-transparent mode, the RLC is responsible for ciphering user data blocks (RLC PDUs). This function prevents 
unauthorized acquisition of data. 
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6.5.2.2.1 Acknowledged Mode 

RLC has support for the following functions in acknowledged mode. For a detailed description, see 3GPP TS 44.060 
and 3GPPTS 44.160. 

- Segmentation of upper layer PDUs into RLC data blocks. 
Concatenation of upper layer PDUs into RLC data blocks. 

- Padding to fill out an RLC data block. 

Backward Error Correction (BEC) procedures enabling the selective retransmission of RLC data blocks. As 
for EGPRS R'99, either selective type I hybrid ARQ or selective type II hybrid ARQ (incremental redundancy) is 
used. 

Discard of RLC SDUs not yet segmented into RLC PDUs, according to the delay requirements of the associated 
Radio Bearer. 

- Reassembly of RLC data blocks into upper layer PDUs. 

- In-sequence delivery of upper layer PDUs. 

- Link Adaptation. 

- Ciphering. 

6.5.2.2.2 Unacknowledged Mode 

RLC has support for the following functions in unacknowledged mode. For a detailed description, see 3GPP TS 44.060 
and 3GPP TS 44.160. No backward error correction procedure is supported in this mode. 

Segmentation of upper layer PDUs into RLC data blocks. 

Concatenation of upper layer PDUs into RLC data blocks. 

- Padding to fill out an RLC data block. 

- Reassembly of RLC data blocks into upper layer PDUs. 

- Sequence number check to detect lost RLC blocks. 
In-order delivery of upper layer PDUs. 

- Link Adaptation. 

- Ciphering. 

6.6 Medium Access Control (MAC) 

This clause provides an overview on services and functions provided by the Medium Access Control (MAC). A detailed 
description of the MAC is given in 3GPP TS 44.060 and 3GPP TS 44.160. 

6.6.1 Services provided to upper layers 

The MAC layer allows the transmission over the physical layer of upper layer PDUs from one mobile station when 
operating on a dedicated basic physical subchannel, or one or more mobile stations when operating on a shared basic 
physical subchannel. The MAC layer handles the access to and multiplexing onto the basic physical subchannels. 

Data transfer. This service provides unacknowledged transfer of MAC SDUs between peer MAC entities. This 
service does not provide any data segmentation. Therefore, segmentation/reassembly function should be 
achieved by upper layer. 
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6.6.2 MAC Functions 

The functions of MAC include: 

- Configuring the mapping between logical channels and basic physical subchannels. The MAC is 

responsible for configuring the mapping of logical channel(s) onto the appropriate basic physical subchannel(s). 

- Defining logical channels to be used for each radio bearer service. This function includes mapping of 
signalling radio bearers onto logical channels. 

- Assignment, reconfiguration and release of shared radio resources for a TBF. The MAC layer may handle 
the assignment of radio resources on SBPSCH(s) needed for a TBF including needs from both the control and 
user plane. The MAC layer may reconfigure radio resources of a TBF on SBPSCH(s). 

- MS measurement reporting and control of the reporting. The MAC layer is responsible for sending 
information that control the MS measurement reporting when using PBCCH or PACCH channels. The MAC 
layer also performs the reporting of the measurements from the MS to the network using PACCH. 

- Broadcasting/listening of/to PBCCH and PCCCH. The MAC layer broadcasts/listens (to) the PBCCH of the 

serving cell for the sending/decoding of packet system information messages. The MAC layer also sends paging 
information on the PCCCH and monitors the paging occasions according to the DRX cycle. Within the Mobile 
Station, the MAC layer notifies the RRC layer when receiving a paging message; within the network, it is 
responsible for aggregating and sending paging messages addressed to one or more Mobile Stations when 
received from the RRC layer. 

Timing advance control. The MAC layer controls the operation of timing advance on shared basic physical 
subchannels. 

6.6.2.1 Additional functions for RLC transparent mode 

When MAC offers services to an RLC entity in transparent mode, the following function is also supported. 
Ciphering. The MAC is responsible for ciphering user data blocks (MAC SDUs). 

6.6.2.2 Additional functions for RLC non-transparent mode 

When MAC offers services to an RLC entity in non-transparent mode, the following functions are supported in addition 
to those listed in section 6.6.2. 

- Ciphering. The MAC layer is responsible for ciphering layer 2 control blocks (RLC/MAC PDUs). 

- Identification of different traffic flows of one or more MSs on the basic physical subchannels. Inband 
identification is needed to address a flow to an MS in the downlink or identify a flow from an MS in the uplink. 

Multiplexing/demultiplexing of higher layer PDUs. This function includes priority handling between data 
flows of one or more mobile stations, e.g. by attributes of Radio Bearer services. 

- Multiplexing/demultiplexing user and control plane data to/from the physical layer. The MAC layer is 
responsible for multiplexing/demultiplexing RLC data blocks and RLC/MAC control blocks. 

- ScheduUng of RLC/MAC data and control PDUs deUvered to the physical layer on shared basic physical 
subchannels. This includes USF and RRBP field monitoring for uplink transfer and sharing radio resources on 
the downlink. 

Splitting/recombining. This includes splitting/recombining of the RLC/MAC PDU flow belonging to one or 
more TBF(s) onto/from several shared logical channels. This function does not apply for RLC/MAC control 
blocks. 

6.6.3 Model of MAC 

The model presented in this section does not mandate how to implement the MAC layer. 

In this model, the functions of MAC are controlled by a MAC control entity and a MAC common control entity. 
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The MAC control entity is specific to an MS. It is controlled by RRC; at RB establishment, the MAC control entity 
sets-up the functions needed to support the Radio Bearer. The MAC control entity can be in one of four states MAC- 
Idle state, MAC-Shared state, MAC-Dedicated state or MAC-DTM state, as defined in Annex C.2. The MAC functions 
listed in the above sub-sections do not apply in every MAC state. 

There is one and only one MAC control entity on the MS side. On the network side, there is one MAC control entity per 
MS. Additionally, there is one MAC common control entity per cell, which is responsible for the control of common 
channels and procedures. 

Figure 12 below shows an example of MAC model to realise a set of Radio Bearers on the MS side (user plane only). It 
shows the MAC Control Entity for that MS, together with some MAC functions that are used in this case. 
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(1): The schediding function in this figure includes multiplexing user and control plane data and 
appending a MAC (possibly combined RLC/MAC) header to the MAC SDU. 



Figure 12. Example of MAC functions for one user (MS side - user plane) 



6.6.4 MAC operation 



6.6.4.1 



General 



The MAC layer uses TBFs (Temporary Block Flows) to offer data transport between peer RLC instances. The MAC 
layer supports transport of data between multiple peer RLC instances established in a single MS and the GERAN. 
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A TBF provides unidirectional data transport on one or more basic physical subchannels of the same type (either 
SBPSCH or DBPSCH). RRC may reconfigure a TBF from using one or more SBPSCHs to using one or more 
DBPSCHs (and vice versa). More than one TBF may be allocated to a single MS in any direction. A TBF may transport 
data for the following combination of RLC instances: 

- A single RLC instance carrying data for a URB. 

- A single RLC instance carrying data for an SRB. 

- A single RLC instance carrying data for a URB or an SRB, and using TBF stealing, one or more RLC instances 
each carrying data for an SRB for which no specific TBF is currently established. This combination is only 
supported by TBFs on SBPSCH. 

Multiple TBFs are supported on all logical channels except TCH and common control channels. 

Any MS operating in lu mode supports multiple TBFs in uplink and downlink. MSs supports 8 uplink TBFs and 8 
downlink TBFs. 

6.6.4.2 TBF establishment 

6.6.4.2.0 General 

Uplink TBFs on SBPSCHs are established as follows: 

- An MS issues a MAC-layer request followed by the GERAN returning a MAC-layer assignment. This is used 
when the MS is in MAC-Idle state, MAC-Shared state, or MAC-DTM state. 

- An MS issues an RRC -layer request followed by GERAN returning an RRC-layer message that assigns TBFs to 
existing RBs on an SBPSCH. This is used when the MS is in MAC-Dedicated state. 

- The GERAN sends an RRC-layer message that sets up or reconfigures RBs on an SBPSCH. This is used when 
the MS is in MAC-Shared state, MAC-Dedicated state, or MAC-DTM state. 

Uplink TBFs on DBPSCHs are established as follows: 

- An MS issues a MAC-layer request followed by the GERAN returning a MAC-layer dedicated assignment. This 
implicitly establishes 4 TBFs for SRBs 1 through 4. This is used when the MS is in MAC-Idle state. 

- The GERAN sends an RRC-layer message that sets up or reconfigures radio bearers on a DBPSCH. This 
implicitly establishes 4 TBFs for SRBs 1 through 4. It may also explicitly establish TBFs and USFs for URBs. 
This is used when the MS is in MAC-Shared state, MAC-Dedicated state, or MAC-DTM state. 

Downlink TBFs on SBPSCHs are established as follows: 

- The GERAN sends a MAC-layer assignment. This is used when the MS is in MAC-Idle state, MAC-Shared 
state, or MAC-DTM state. 

- The GERAN sends an RRC-layer message that sets up or reconfigures RBs on an SBPSCH. This is used when 
the MS is in MAC-Shared state, MAC-Dedicated state, or MAC-DTM state. 

Downlink TBFs on DBPSCHs are established as follows: 

- The GERAN sends a MAC-layer dedicated assignment. This implicitly establishes 4 TBFs for SRBs 1 through 
4. The GERAN may send the MAC-layer dedicated assignment in response to an MS issuing a MAC-layer 
request. This is used when the MS is m MAC-Idle state. 

- The GERAN sends an RRC-layer message that sets up or reconfigures RBs on a DBPSCH. This implicitly 
establishes 4 TBFs for SRBs 1 throguh 4. It may also explicitly establish TBFs for URBs. This is used when the 
MS is in MAC-Shared state, MAC-Dedicated state, or MAC-DTM state. 
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6.6.4.2.1 Uplink resource request from MAC-ldle state 

6.6.4.2.1 .1 Mobile Originated Transmission 

When the mobile station is in MAC-ldle state and requests the establishment of a TBF or dedicated resource, an 
RLC/MAC control message (PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST message) 
is sent on the PRACH. In this message, the mobile station indicates one establishment cause from the following list:- 

"Single Block Without TBF Establishment", "One Phase Access Request", "One Phase Access Request in RLC 
unack mode", "Short Access Request", "Two Phase Access Request", "MM Procedure", "Dedicated channel 
request", "Emergency call" 

To establish a TBF for a user radio bearer, one of the following is used:- 

"One Phase Access Request", "One Phase Access Request in RLC unack mode", "Short Access Request", "Two 
Phase Access Request" 

To establish a TBF or dedicated resource for a signalling radio bearer, one of the following is used:- 

"Single Block Without TBF Establishment", "MM Procedure", "Dedicated channel request", "Emergency call" 

Note that "Page Response" and "Cell Update" establishment causes are only to be used in A/Gb mode. 

6.6.4.2.1 .2 Mobile Terminated Transmission 

For mobile terminated transmission, when a paging request message containing a paging cause is sent to the mobile 
station, the mobile station requests resources on the PRACH using one of two establishment causes as follows:- 

To respond to paging causes "Terminating Conversational Call" or "Terminating Streaming Call" the mobile station 
indicates:- 

"Dedicated channel request" 

To respond to paging causes "Terminating Interactive Call", "Terminating Background Call", "Terminating High 
Priority Signalling", "Terminating Low Priority Signalling", or "Terminating - cause unknown" the mobile station 
indicates:- 

- "MM Procedure" 

6.6.4.3 TBF multiplexing and scheduling 

6.6.4.3.1 Multiplexing of RLC instances on TBFs 

When one TBF carries data for one RLC instance, multiplexing is trivial. This case is analogous to REL-4 and previous 
releases. 

When one TBF, in addition to a first RLC instance, carries data for one or more RLC instances, each carrying data of an 
SRB for which no specific TBF is currently established, the MAC layer uses TBF stealing to multiplex data from these 
RLC instances onto the TBF. This stealing mechanism allows the MAC layer to send SRB data without signalling to set 
up a separate TBF. To send data using this mechanism, the GERAN or MS MAC layer performs the following: 

- It selects one of the TBFs currently established on an SBPSCH for the MS in question. 

- It adds the SRBid to the RLC/MAC header to allow the receiving MAC entity to detect that TBF stealing is used 
and to forward the received data to the correct RLC instance. 

- It sends the SRB-related data in the next scheduling opportunity for the selected TBF. 

6.6.4.3.2 Scheduling of TBFs on physical-layer resources 

TBFs are scheduled on a radio-block basis according to their QoS attributes. 
An established uplink TBF is scheduled as follows: 
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- On an SBPSCH, the MS sends data for the TBF that corresponds to the received USF. If no TBF corresponds to 
the received USF, the MS does not send. 

- On a DBPSCH with a PDTCH-type channel combination, if the MS has more than one TBF with data to send, 
the MS sends data for the TBF that corresponds to the received USF. If the MS has nothing to send for the 
scheduled TBF, and if the MS has data to send for one or more other TBFs mapped onto the same BPSCH, the 
MS sends data from one of these other TBFs. 

- On a DBPSCH with a PDTCH-type channel combination, if the MS has only one TBF with data to send, the MS 
ignores the USF and sends data for that TBF. This allows the GERAN to reduce downlink interference by not 
transmitting if there is no downlink data to send. 

- On a DBPSCH with a PDTCH-type channel combination, when a previously inactive TBF again has data to 
send, the MS shall send one data block for this TBF the next time the GERAN schedules any of the MS's TBFs. 
This notifies GERAN that this TBF has again become active. The GERAN decodes the TFI and then schedules 
this TBF according to its QoS attributes. To handle the case where the GERAN fails to decode the TFI in the 
data block from this TBF, a repetition scheme is standardized for the MS. 

- On a DBPSCH with a TCH-type channel combination, the multiframe structure and MS stealing rules determine 
which TBFs are scheduled, analogous to CS operation for REL-4. 

An established downlink TBF is scheduled by the GERAN. 

6.6.4.4 TBF release 

An uplink TBF is released as follows: 

- On an SBPSCH, the GERAN releases the TBF by sending a PACKET UPLINK Ack/Nack with the final ack 
indicator set to 1 . 

- On a DBPSCH, the GERAN releases the TBF by releasing the DBPSCH, by releasing the corresponding radio 
bearer, or by reconfiguring the corresponding radio bearer to another BPSCH. 

A downlink TBF is released as follows: 

- On an SBPSCH, the GERAN initiates release by sending a data block with final block indicator set to 1. The MS 
acknowledges the release. 

- On a DBPSCH, the GERAN releases the TBF by releasing the DBPSCH, by releasing the corresponding radio 
bearer, or by reconfiguring the corresponding radio bearer to another BPSCH. 

6.6.4.5 TBF reallocation 

Considering the mobile station's multislot capabilities, GERAN may reallocate one or more of a mobile station's TBFs: 

- To a different radio frequency or a different hopping sequence. All of a mobile station's TBFs operate on one 
radio frequency or one hopping sequence. 

- To different timeslots (the same number, more, or fewer). 

- To use a different TFI for a given TBF. 

- To use different USFs for a given uplink TBF. 

- To use different coding schemes or modulation-and-coding schemes. 
This reallocation may be in response to a mobile-station request. 

When only SBPSCHs are allocated, GERAN MAC or GERAN RRC signals the reallocation. 
When at least one DBPSCH is allocated, GERAN RRC signals the reallocation. 
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6.7 RLC/MAC PDU Formats for different protocol modes 

6.7.1 Acknowledged RLC mode 

The GPRS/EGPRS channel codes RLC/MAC header and coding schemes (CS-1, ... ,CS-4 and MCS-1, ... , MCS-9) are 
used. Other coding schemes are CSD/ECSD. 

6.7.2 Unacknowledged RLC mode 

The GPRS/EGPRS channel codes RLC/MAC header and coding schemes (CS-1, ... ,CS-4 and MCS-1, ... , MCS-9) are 
used. Other coding schemes are CSD/ECSD when operating on a dedicated basic physical subchannel. 

6.7.3 Transparent RLC mode 

The transparent mode is used for example to transmit voice in GERAN. The different channel coding schemes used for 
voice in GSM are used. New coding schemes for 8-PSK half rate and possibly full rate speech are also required. Other 
coding schemes like e.g. CSD/ECSD is FES. 

Since RLC is used in transparent mode, no RLC/MAC header has to be added. 

6.8 Physical Layer (Phy) 

The physical layer (layer 1) is the lowest layer in the OSI Reference Model and it supports all functions required for the 
transmission of bit streams on the physical medium. This clause provides an overview on services and functions 
provided by the Physical Layer. A detailed description of the physical layer is given in [Ref: 05 series]. 

6.8.1 Definitions 

A physical channel uses a combination of frequency and time division multiplexing and is defined as a sequence of 
radio frequency channels and time slots. The complete definition of a particular physical channel consists of a 
description in the frequency domain, and a description in the time domain [11]. 

A basic physical channel is defined as a sequence of radio frequency channels and time slots. The basic physical 
channel uses the same timeslot in every TDMA frame. The TDMA frame number sequence is 0,1,.. FN_MAX, where 
FN_MAX is the maximum TDMA frame number for a hyperframe (i.e. all TDMA frames on a timeslot). 

A basic physical subchannel is defined as a basic physical channel or a part of a basic physical channel and an 
associated multiframe structure. A basic physical subchannel can either be shared or dedicated. Example: DBPSCH/F. 

A logical channel is defined by the type of data which is transferred and characterized by parameters such as channel 
coding and interleaving. It can be uni-directional or bi-directional [11]. Example: PDTCH/U, TCH/FS, FACCH/F. 

A channel combination is defined as the combination of logical channels that is mapped on a certain basic physical 
subchannel. Example: TCH/FSh-FACCH/Fh-SACCH/TF. The channel combination could also be mapped onto a basic 
physical channel, example: TCH/H(0,1)h-FACCH/H(0,1)h-SACCH/TH(0,1) [11]. 



6.8.2 Services provided to upper layer 



The physical layer interfaces the Medium Access Control (MAC) sub-layer of Layer 2 and the Radio Resource Control 
(RRC) sub-layer of Layer 3. Through Service Access Points (SAP), the physical layer offers services described below: 

Access capabilities: the physical layer offers logical channels and the transmission services associated to higher 
layers. Logical channels are multiplexed either in a fixed predefined manner (multiframe structure) or 
dynamically by the MAC on basic physical subchannels. Basic physical subchannels are the units scheduled on 
the radio medium. Some are reserved by the network for common use (e.g. for use by a combination of PCCCH 
and PBCCH), others are assigned to dedicated connections with MSs (dedicated basic physical subchannels), or 
are assigned to a shared usage between MSs (shared basic physical subchannels). 
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Error detection: the physical layer offers an error protected transmission service, it includes error detection 
functions and to a lower level, error correction functions. Erroneous received frames may be notified to upper 
layer and, depending on the need of the upper layer, offered to it. The probability of one or more errors in a 
physical block transferred by the physical layer is defined in 3GPP TS 45.005. Due to non specified methods of 
quality detection, the probability of residual errors in transferred blocks may vary between implementations. 

6.8.2.1 Specific services of the physical layer in the MS 

Measurement of the signal strength of neighbouring base stations. Measurements are transferred to layer 3. 

Measurement of the signal quality of the basic physical subchannel used. Measurements are transferred to the 
MAC layer for reporting to the base station. 

Cell/PLMN selection in idle mode or in packet mode. In idle mode or in packet mode, the physical layer selects 
the best cell with its BCCH (CPBCCH only for COMPACT and for packet mode only) in close co-operation 
with layer 3, meeting requirements for PLMN selection specified in 3GPP TS 42.01 1. 

6.8.3 Logical Channels 

6.8.3.1 Traffic channels 

Traffic channels of type TCH are intended to carry either encoded speech or user data on dedicated basic physical 
subchannel. TCH can be either full rate (TCH/F) or half rate (TCH/H). 

Traffic channels of type O-TCH are intended to carry encoded speech on dedicated basic physical subchannel. O-TCH 
can be either full rate (O-TCH/F) or half rate (O-TCH/H). 

Traffic channels of type E-TCH are intended to carry user data on dedicated basic physical subchannels. 

Packet data traffic channels (PDTCH) are intended to carry user data on either dedicated or shared basic physical 
subchannels. PDTCH's can be either full rate (PDTCH/F) or half rate (PDTCH/H). 

6.8.3.2 Control channels 

Control channels carry signalling or synchronization data. Four categories of control channels are defined: broadcast, 
common, dedicated control channels and cell broadcast channels. Specific channels within these categories are defined 
in the clauses following. 

6.8.3.2.1 Broadcast channels 

GERAN shall reuse Release 99 broadcast channels. Any addition shall be made in a backwards compatible manner. 

6.8.3.2.2 Common control type channels 

GERAN common control type channels shall be based on Release 99 common control type channels. Any addition shall 
be made in a backwards compatible manner. 

6.8.3.2.3 Dedicated control channels 

On a dedicated basic physical subchannel: 

i) The Fast Associated Control channel (FACCH) associated to one TCH. FACCH can either be full rate 
(FACCH/F, E-FACCH/F, O-FACCH/F) or half rate (FACCH/H, O-FACCH/H) depending whether it is 
associated to a full rate or half rate TCH. 

ii) The Packet Associated Control channel (PACCH) associated to one PDTCH: The PACCH is bi-directional. 
PACCH/U is used for the uplink and PACCH/D for the downlink. PACCH can either be full rate (PACCH/F) or 
half rate (PACCH/H) depending whether it is associated to a full rate or half rate PDTCH. 

iii) The Slow Associated Control channel (SACCH) associated to one TCH or PDTCH. SACCH can either be full 
rate (S ACCHATF) or half rate (S ACCH/TH) depending whether it is associated to a full rate or half rate TCH or 



£75/ 



3GPP TS 43.051 version 5.10.0 Release 5 38 ETSI TS 143 051 V5.10.0 (2003-08) 

PDTCH. Further, the SACCH can be associated either to a TCH or PDTCH where EPC is not deployed 
(SACCH/T) or a TCH or PDTCH where EPC is deployed (SACCH/TP). 

iv) The Enhanced Power Control channel (EPCCH) associated to one TCH or PDTCH. EPCCH can be either full 
rate (EPCCH/F) or half rate (EPCCH/H) depending on whether it is associated to a full rate or half rate TCH or 
PDTCH. 

v) The Stand-alone Dedicated Control Channel (SDCCH) is a bi-directional dedicated control channel whose 
allocation is not Hnked to the allocation of a TCH [UMTS 45.003]. 

vi) The Enhanced Inband Associated Control Channel (E-IACCH/F) associated to one E-TCH/F. 

On a shared basic physical subchannel: 

i) The Packet Associated Control channel (PACCH): The PACCH is bi-directional. PACCH/U is used for the 
uplink and PACCH/D for the downlink. PACCH can either be full rate (PACCH) or half rate (PACCH/H) 
depending whether it is associated to a full rate or half rate PDTCH. 

ii) The Packet Timing advance Control CHannel uplink (PTCCH/U): Used to transmit random access bursts to 
allow estimation of the timing advance for one MS in packet transfer mode. 

iii) The Packet Timing advance Control CHannel downlink (PTCCH/D): Used to transmit timing advance updates 
for several MS. One PTCCH/D is paired with several PTCCH/U's. 

6.8.3.2.4 Cell Broadcast Channel (CBCH) 

GERAN shall reuse Release 99 cell broadcast channel. 

6.8.4 Basic Physical Subcinannels 

A basic physical subchannel can either be dedicated or shared. 

All basic physical subchannels are bi-directional unless otherwise stated. 

6.8.4.1 DBPSCH - Dedicated Basic Physical SubCHannel 

A DBPSCH is for only one user and it always has an associated SACCH. A DBPSCH can either be full rate or half rate. 

6.8.4.2 SBPSCH - Shared Basic Physical SubCHannel 

A SBPSCH is for one or more users. A SBPSCH can either be full rate or half rate. 

6.8.5 Mapping of logical channels onto basic physical subchannels 
6.8.5.1 DBPSCH full rate 

The following channel combinations are possible for a DBPSCH full rate: 

i) TCH/F + FACCH/F + SACCH/TF; 

ii) TCH/F + FACCH/F + SACCH/TPF + EPCCH/F; 

iii) PDTCH/F + PACCH/F + SACCH/TF; 

iv) PDTCH/F + PACCH/F + SACCH/TPF + EPCCH/F; 

v) E-TCH/F + E-FACCH/F + SACCH/TF + E-IACCH/F; 

vi) O-TCH/F + 0-FACCH/F + SACCH/TF; 

vii) O-TCH/F + O-FACCH/F + SACCH/TPF + EPCCH/F. 
Figure 13 shows the multiframe mapping of the logical channels for DBPSCH/F. 
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Figure 13: DBPSCH/F - Multiframe mapping of logical channels 

Note: When EPC is used, the EPCCH is mapped on the bits of the SACCH bursts. 

6.8.5.2 DBPSCH half rate 

The following channel combinations are possible for a DBPSCH half rate: 

i) TCH/H + FACCH/H + SACCH/TH; 

ii) TCH/H + FACCH/H + SACCH/TPH + EPCCH/H; 

iii) O-TCH/H + O-FACCH/H + SACCH/TH; 

iv) O-TCH/H + O-FACCH/H + SACCH/TPH + EPCCH/H; 

v) PDTCH/H + PACCH/H + SACCH/TH; 

vi) PDTCH/H + PACCH/H + SACCH/TPH + EPCCH/H. 
Figure 14 shows the multiframe mapping of the logical channels for DBPSCH/H. 
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Figure 14: DBPSCH/H - Multiframe mapping of logical channels 

Note: When EPC is used, the EPCCH is mapped on the bits of the SACCH bursts. 

6.8.5.3 SBPSCH full rate 

Excluding CBCH, broadcast channels and common control type channels, the following channel combination is 
possible for a SBPSCH full rate: 

- PDTCH/F + PACCH/F + PTCCH/F. 
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Figure 15 shows the multiframe mapping of the logical channels for SBPSCH/F. Only half of the 52-multiframe is 
shown, the second half being identical to the first one. 
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Figure 15: SBPSCH/F - Multiframe mapping of logical channels 
6.8.5.4 SBPSCH half rate 

The following channel combination is possible for a SBPSCH half rate: 

- PDTCH/H + PACCH/H. 

Figure 16 shows the multiframe mapping of the logical channels for SBPSCH/F. Only half of the 52-multiframe is 
shown, the second half being identical to the first one. 
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Figure 16: SBPSCH/H - Multiframe mapping of logical channels 

6.8.6 Physical Layer Functions 

An overview of the functions which create the services of the physical layer can be found in 3GPP TS 45.001. 

6.8.7 Channel Coding 

Table 2 gives an overview of the logical traffic channels with the corresponding type of channel and their mapping to 
basic physical subchannel. The list shall be considered as the possible, but not mandatory, channels. 
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Table 2: Channel Coding 



Logical Channel 


IVIod. 


Radio Block / 
Frame Size (Bits) 


SB 


Channel Coding 


Interleaving 


Basic 

Physical 

Subchannel 


Type 


Rate 


Tvoe "^P*"^ 
■yP® (bursts) 


TCH/FS [tbd] (2) 


GMSK 


464 


8 


CC 


1 3 kbps 


diag 


8 


DBPSCH/F 


TCH/EFS [tbd] (2) 


GMSK 


464 


8 


CC 


12.2 kbps 


diag 


8 


DBPSCH/F 


TCH/WFS [tbd] (3) 


GMSK 


464 


8 


CC 


[tbc] 


diag 


8 


DBPSCH/F 


0-TCH/WFS[tbd] (3) 


8PSK 


1392 


24 


CC 


[tbcl 


diag 


8 


DBPSCH/F 


0-TCH/WHS [tbd] (3) 


8PSK 


696 


12 


CC 


[tbc] 


diag 


4 


DBPSCH/H 


TCH/HS [tbd] (2) 


GMSK 


232 


4 


CC 


5.6 kbps 


diag 


4 


DBPSCH/H 


TCH/AFS 


GMSK 


464 


8 


CC 


TCH/AFS4.75 
TCH/AFS5.15 
TCH/AFS5.90 
TCH/AFS6.70 
TCH/AFS7.40 
TCH/AFS7.95 
TCH/AFS10.2 
TCH/AFS12.2 


diag 


8 


DBPSCH/F 


TCH/AHS 


GMSK 


232 


4 


CC 


TCH/AHS4.75 
TCH/AHS5.15 
TCH/AHS5.90 
TCH/AHS6.70 
TCH/AHS7.40 
TCH/AHS7.95 


diag 


4 


DBPSCH/H 


0-TCH/AHS 


8PSK 


696 


12 


CC 


0-TCH/AHS4.75 
0-TCH/AHS5.15 
O-TCH/AHS5.90 
O-TCH/AHS6.70 
O-TCH/AHS7.40 
0-TCH/AHS7.95 
O-TCH/AHS10.2 
0-TCH/AHS12.2 


diag 


4 


DBPSCH/H 


TCH/F 


GMSK 


464 


8 


CC 


TCH/F9.6 
TCH/F14.4 


diag 


22 


DBPSCH/F 


E-TCH/F 


8PSK 


1392 


24 


RS+C 

c 


E-TCH/F28.8 
E-TCH/F32.0 


diag 


22 


DBPSCH/F 


CC 


E-TCH/F43.2 


PDTCH/F 


GMSK 


464 


8+4 


CC 


MCS1-4 


rect 


4 


SBPSCH/F 


8 


CS1-4 


8+4 


MCS1-4 


DBPSCH/F 


8 


CS1-4 


8+4 


MCS1-4 


ffs 


ffs 


DBPSCH/F 


8 


CS1-4 


8PSK 


1392 


8 


MCS5-9 


rect 


4 


SBPSCH/F 


8 


MCS5-9 


DBPSCH/F 


8 


MCS5-9 


ffs 


ffs 


DBPSCH/F 


PDTCH/H 


GMSK 


464 


8+4 


CC 


MCS1-4 


rect 


4 


SBPSCH/H 


8 


CS1-4 


8+4 


MCS1-4 


DBPSCH/H 


8 


CS1-4 


8+4 


MCS1-4 


ffs 


ffs 


DBPSCH/H 


8 


CS1-4 


8PSK 


1392 


8 


MCS5-9 


rect 


4 


SBPSCH/H 


8 


MCS5-9 


DBPSCH/H 


8 


MCS5-9 


ffs 


ffs 


DBPSCH/H 


(2) The possibility to establisli TCH/EFS, TCH/FS, TCH/HS speech channels is to be decided by 3GPP SA2 
CC: Convolutional Code. 
RS: Reed Solomon code. 



The table above remains to be completed. 
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Except for the already existing logical channels, the 8PSK modulated logical channels are indicated by an "0-" prefix 
(as in Octal PSK). 

Table 3 gives an overview of the logical control channels used for speech and circuit switched data, and their associated 
logical traffic channel. 

Table 3: Control channel coding 



Logical 
Channel 


Mod. 


Radio Block/ 

Frame Size 

(Bits) 


SB 


Channel Coding 


Interleaving 


Associated 

logical traffic 

channel 


Type 


Rate 


Type 


Depth 
(bursts) 


FACCH/F 


GMSK 


464 


8 


CC 


9.2 kbps 


diag 


8 


TCH/F 


0-FACCH/F 


8PSK 


1392 


24 


cc 


9.2 kbps 


diag 


8 


0-TCH/F 


FACCH/H 


GMSK 


464 


8 


CC 


4.6 kbps 


diag 


6 


TCH/H 


0-FACCH/H 


8PSK 


1392 


24 


cc 


4.6 kbps 


diag 


6 


0-TCH/H 


SACCH/F 


GMSK 


464 


8 


cc 


184/480 kbps 


block 


4 


TCH/F, E- 

TCH/F & 0- 

TCH/F 


SACCH/H 


GMSK 


464 


8 


cc 


184/480 kbps 


block 


4 


TCH/H & 0- 
TCH/H 


SACCH/TPF 


GMSK 


416 


8 


cc 


184/480 kbps 


block 


4 


TCH/F & 0- 

TCH/F 

with EPC 


SACCH/TPH 


GMSK 


416 


8 


cc 


184/480 kbps 


block 


4 


TCH/H & 0- 

TCH/H 

with EPC 


E-FACCH/F 


GMSK 


464 


8 


cc 


9.2kbps 


block 


4 


E-TCH/F 


E-IACCH/F 


8PSK 


24 


- 


BC 


3/20 kbps 


- 


4 


E-TCH/F 


EPCCH/F 


GMSK 


12 


- 


BC 


3/120 kbps 


- 


1 


TCH/F & 0- 

TCH/F with 

EPC 


EPCCH/H 


GMSK 


12 


- 


BC 


3/1 20 kbps 


- 


1 


TCH/H & 0- 

TCH/H with 

EPC 



CC: Convolutional Code. 

BC : Block code 



Except for the already existing logical channels, the 8PSK modulated logical channels are indicated by an "0-" prefix 
(as in Octal PSK). 



6.6.8 EnhancecJ Power control procedure 



In addition to the normal power control, an enhanced power control scheme (EPC) shall be supported by the MS and 
may optionally be supported by the BSS, when operating on a DBPSCH. 

EPC has a reporting period of 26 TDMA frames (120 ms). A dedicated control channel, the EPCCH, is used for the 
purpose of EPC. For MS power control, EPC power commands are sent on the downlink EPCCH. For BTS power 
control, EPC measurement reports are sent on the uplink EPCCH. 

If EPC is in use, the normal SACCH (SACCH/TF or SACCH/TH) is replaced by a modified SACCH (SACCH/TPF or 
SACCH/TPH). The EPCCH is multiplexed with the SACCH/TP. One EPCCH frame is multiplexed with each burst of 
the SACCH/TP. The multiplexing is done on the physical layer. 
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6.8.8.1 MS implementation 

Enhanced power control shall be implemented in the MS. 

When on a DBPSCH, the MS shall use EPC, if so indicated by the BSS in the ASSIGNMENT COMMAND or 
HANDOVER COMMAND (see 3GPP 44.018). 



6.8.8.1.1 



MS power control 



If EPC is in use, the MS shall employ the most recently commanded EPC level on each uplink DBPSCH. The power 
level to be employed by the MS is indicated by means of the EPC power command sent via EPCCH once every EPC 
reporting period. The MS shall report, in the SACCH LI header, the RE power level used at the end of the normal 
power control reporting period. 

NOTE: The term "normal power control" is used in this specification for clarification and is otherwise referred to 
as "power control". 

The enhanced power control scheme is based on differential control to adjust the employed RF power level. The 
possible EPC power commands are the same as for fast power control used for ECSD [3GPP TS 45.008]. 

6.8.8.1 .2 MS link quality measurement reports 

When employing EPC, the MS shall use the uplink EPCCH for EPC measurement reporting. 

For each DBPSCH on which EPC is in use, the received signal quality shall be measured by the MS in a manner that 
can be related to the average BER before channel decoding, assessed over one EPC reporting period. 

The average BER shall for every EPC reporting period be mapped to the RXQUAL scale according to 45.008 [], 
producing the parameter RXQUAL_EPC which is reported to the network via EPCCH. 

6.8.8.2 BSS implementation 

Enhanced power control may optionally be implemented in the BSS. 



Ciphering 



The ciphering architecture is specified in 3GPP TS 33.102 and is identical to that of UTRAN (f8). The ciphering 
principle with input parameters to the algorithm is illustrated in figure 17. 



Ciphering 
Key 



Count Direction Bearer 

_J i L 



Plain Text (Length L) 



Mask Generator 



Mask (Length L) 



XOR 



Ciphered Text (Length L) 



Figure 17: Ciphering Principle 

Ciphering shall be applied after contention resolution has been performed provided the MS is under coverage of its 
serving BSS. It is FES how it is performed when the controlling RAN node is not the serving RAN node. 
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7.1 Location of ciphering in the GERAN protocol architecture 

The ciphering function is performed either in the RLC sub-layer or in the MAC sub-layer, according to the following 
rules: 

In case of non-transparent RLC mode (acknowledged or unacknowledged), ciphering is performed in the RLC 
sub-layer for layer 2 user data blocks only. Layer 2 signalling is ciphered in the MAC sub-layer. 

In case of transparent RLC mode, ciphering is performed in the MAC sub-layer. 

According to this model, ciphering when applied is performed in the BSS and the MS, and the context needed for 
ciphering (input parameters) is only known in BSS and the MS. 

7.2 Inputs to the ciphering algorithm 

7.2.1 Ciphering Key 

The ciphering key is 128 bit long. 

The ciphering key is established between the MS and BSS during the authentication phase. In the two-key solution, the 
CS-domain user-plane bearers are ciphered with the most recent cipher key agreed between the user and the MSC (CK- 
CS). The PS-domain user-plane bearers are ciphered with the most recent cipher key agreed between the user and the 
SGSN (CK-PS). 

The signalling radio bearers are used for transfer of signalling data for services delivered by both CS and PS service 
domains. These signalling radio bearers are ciphered using the CK of the service domain for which the most recent 
security mode negotiation took place. This may require that the cipher key of an (already ciphered) ongoing signalling 
connection has to be changed, when a new connection is established with another service domain, or when a security 
mode negotiation follows a re-authentication during an ongoing connection. 

To ensure performing the right ciphering function at the RLC and MAC layers, three conditions must be met: 

A user -plane Radio Bearer is either from CS-domain or PS-domain, but not from both. 

RRC maps a given user -plane Radio Bearer to a given domain in order to derive the correct key to utilise for 
each RB. 

The RLC and MAC layers receive the Radio Bearer IDs and CKs they should use from RRC. 

7.2.2 Bearer 

This parameter indicates the radio bearer identity (when available), which shall be unique within a RRC connection. It 
is used as input parameter to the ciphering algorithm to ensure that the same ciphering mask is not applied to two or 
more parallel Radio Bearers having the same ciphering key and count. Each Radio Bearer is ciphered independently. 

In case no radio bearer identity is available (layer 2 signalling), the data id shall be equal to a unique value. 

To ensure that the same ciphering mask is not applied to layer 2 signalling (no RBid available) and layer 2 user data 
(RBid available), RBid indicator is used in the count parameter to inform whether RBid is available or not. 

7.2.3 Direction 

This parameter indicates the direction of transmission (uplink/downlink). 

7.2.4 Length 

This parameter indicates the length of the mask to be generated by the algorithm (this length is equal to that of the data 
to be ciphered). It is not an input to the mask generator. 



£75/ 



3GPP TS 43.051 version 5.10.0 Release 5 



45 



ETSI TS 143 051 V5.10.0 (2003-08) 



7.2.5 Parameter Settings 

The following tables defines how to set the input parameters to the ciphering algorithm that applies to layer 2 user data 
blocks and layer 2 signalling respectively: 

Table 4: Input parameters for user data blocks 



Input 
parameters 


Size 
(bits) 


Non-transparent RLC Mode 


Transparent RLC Mode 


Count 


32 


RLC Sequence Number: a) 7 bits or b) 11 bits 
a)0...127orb)0...2047 


Slot number: 3 bits 
0...7 


RBId indicator: 1 bit 
1 (RBid available) 


HFN: 24 or 20 bits 

a) 0... 1677721 5 or b) 0...1 048575 


TDIVIA Frame Number: 17 bits (see note 1) 


HFN: 11 bits 
0...2047 


Direction 


1 


1 bit 

(Uplink) or 1 (Downlink) 


Bearer 


5 


Radio Bearer Identifier (RBid) 
0...31 


Length 


16 


Length of the input data to be ciphered: the 
fields included in the input parameters shall not 
be ciphered. 
0... 65535 


Full block size 


NOTE 1 : The construction of the 17-bit TDIVIA Frame Number is described in 3GPP TS 44.160. 



Table 5: Input Parameters for layer 2 signalling 



Input 
parameters 


Size 
(bits) 


Non-transparent RLC mode 


Count 


32 


Slot number: 3 bits 
0...7 


RBid indicator: 1 bit 
(RBid not available) 


TDIVIA Frame Number: 17 bits (see note 1 in 
table 4) 


HFN: 11 bits 
0...2047 


Direction 


1 


1 bit 

(Uplink) or 1 (Downlink) 


Bearer 


5 


"00000" 


Lengtii 


L 


Full block size 



8 Integrity protection 

8.1 Integrity protection on RRC messages 

Integrity protection with a 32-bit MAC-I shall be performed on all RRC messages, with the exceptions defined in 
3GPPTS 44.118. 

There may be one IK for CS connections (IKcs), established between the CS service domain and the user and one IK for 
PS connections (IKps) established between the PS service domain and the user. 

The data integrity of radio bearers for user data is not protected. 

The signalling radio bearers are used for transfer of signalling data for services delivered by both CS and PS service 
domains. These signalling radio bearers are data integrity protected by the IK of the service domain for which the most 
recent security mode negotiation took place. This may require that the integrity key of an (already integrity protected) 
ongoing signalling connection has to be changed, when a new connection is established with another service domain, or 
when a security mode negotiation follow a re-authentication during an ongoing connection. 
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8.2 Integrity protection on RLC/IVIAC control messages 

RLC/MAC control messages are not integrity protected. 

8.3 Calculation of message authentication code 

The MS shall calculate the message authentication code in accordance with 3GPP TS 33.102. The construction of the 
input parameter MESSAGE (3GPP TS 33.102) for the integrity algorithm is FFS. 

9 Mobility Management and Session Management 
(MM and SM) 

See 3GPP TS 24.008. 

10 Sequence Diagrams Examples for Handover 

See 3GPP TS 45.008, and 3GPP TS 25.931. 
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Annex A (informative): 

Radio Access Bearer Realization 



This annex describes how the different protocols of the GERAN User Plane protocol stack are configured to provide the 
desired radio access bearer classes (conversational, streaming, interactive and background). Only the traffic over lu-ps 
interface is considered. 



A.1 Conversational Radio Access Bearer 

In table A. 1, case A represents optimized conversational RAB further described in clause A. 1.2. Case B represents the 
generic conversational RAB. 
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Table A.I : Conversational RAB 



PDCP 



RLC 



lUIAC 



Physical Layer 



Basic 

Physical 

Subchannel 



Traffic Channel 



Type 



Interleav. 



Mod. 



Coding 



Dedicated 
Control 
Channel 



GMSK 



UEP 



DBPSCH/F 



TCH/F 



8 diag 



Non 

Transparen 

t 

Header Removal 



8PSK(1) 



UEP 



Transp. 



Non 

Transparen 

t 

Header 

Compression 

or No Adaptation 

Transparen 
t 



Dedicate 
d 



GMSK 



UEP 



DBPSGH/H 



TCH/H 



4 diag 



8PSK 



UEP 



As 
TCH/AFS 



FACCH/F (2) 

SACCH/TF or 

SACCH/TPF + 

EPCCH/F 



ffs 



FACCH/F (2) 

SACCH/TF or 

SACCH/TPF + 

EPCCH/F 



As 
TCH/AHS 



FACCH/H (2) 

SACCH/TH or 

SACCH/TPH + 

EPCCH/H 



As 
TCH/AHS 



FACCH/H (2) 

SACCH/TH or 

SACCH/TPH + 

EPCCH/H 



Unack 



Dedicate 
d 



GMSK 



EEP 



PDTCH/F 



4 rect 



SACCH/TF or 

SACCH/TPF + 

EPCCH/F 

PACCH/F 



8PSK 



EEP 



DBPSCH/F 



SACCH/TF or 

SACCH/TPF + 

EPCCH/F 

PACCH/F 



GMSK 



EEP 



TCH/F 
(2) 



ffs 



FACCH/F (2) 

SACCH/TF or 

SACCH/TPF + 

EPCCH/F 



8PSK 



EEP 



FACCH/F (2) 

SACCH/TF or 

SACCH/TPF + 

EPCCH/F 



DBPSCH/H 



GMSK 



EEP 



PDTCH/ 
H 



4 rect 



SACCH/TH or 

SACCH/TPH + 

EPCCH/H 

PACCH/H 



8PSK 



EEP 



SACCH/TH or 

SACCH/TPH + 

EPCCH/H 

PACCH/H 



£75/ 



3GPP TS 43.051 version 5.10.0 Release 5 



49 



ETSI TS 143 051 V5.10.0 (2003-08) 



TCH/H 



ffs 



GMSK 



EEP 



FACCH/H 
SACCH/TH or 
SACCH/TPH + 

EPCCH/H 



UEP Unequal Error Protection - EEP Equal Error Protection. 

(1) This row is intended for the realization of wide-band speech codec and is ffs. 

(2) Whether FACCH and PACCH are both needed is ffs. 
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A.2 Streaming, Interactive, Background Radio Access Bearers 



A.2.1 Streaming 



Table A.2: Streaming RAB 



PDCP 


RLC 


lUIAC 


Physical Layer 




Basic 

Physical 

Subchannel 


Traffic Channel 


Dedicated 
Control 
Channel 




Type 


Interleav. 


Mod. 


Coding 




Non 
Transparent 

Header 

Compressio 

n 

or No 

Adaptation 

Transparent 


Unacl< 


Dedicated 


DBPSCH/F 


PDTCH/F 


4 rect 


GMSK 


EEP 


SACCH/TF or 

SACCH/TPF + 

EPCCH/F 

PACCH/F 




8PSK 


EEP 


SACCH/TF or 

SACCH/TPF + 

EPCCH/F 

PACCH/F 




TCH/F 


ffs 


GMSK 


EEP 


FACCH/F{1) 

SACCH/TF or 

SACCH/TPF + 

EPCCH/F 


A 


8PSK 


EEP 


FACCH/F{1) 

SACCH/TF or 

SACCH/TPF + 

EPCCH/F 


DBPSCH/H 


PDTCH/H 


4 rect 


GMSK 


EEP 


SACCH/TH or 

SACCH/TPH + 

EPCCH/H 

PACCH/H 




8PSK 


EEP 


SACCH/TH or 

SACCH/TPH + 

EPCCH/H 

PACCH/H 




TCH/H 


ffs 


GMSK 


EEP 


FACCH/H(1) 

SACCH/TH or 

SACCH/TPH + 

EPCCH/H 




Non 
Transparent 

Header 
Compressio 


Acl< 


Dedicated 


DBPSCH/F 


PDTCH/F 


4 rect 


GMSK 


EEP 


SACCH/TF or 

SACCH/TPF + 

EPCCH/F 

PACCH/F 


B 
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PDCP 


RLC 


MAC 


Physical Layer 




Basic 

Physical 

Subchannel 


Traffic Channel 


Dedicated 
Control 
Channel 




Type 


Interleav. 


Mod. 


Coding 




n 

or No 

Adaptation 

Transparent 












8PSK 


EEP 


SACCH/TF or 

SACCH/TPF + 

EPCCH/F 

PACCH/F 




DBPSCH/H 


PDTCH/H 


4 rect 


OMSK 


EEP 


SACCH/TH or 

SACCH/TPH + 

EPCCH/H 

PACCH/H 




8PSK 


EEP 


SACCH/TH or 

SACCH/TPH + 

EPCCH/H 

PACCH/H 




Non 
Transparent 

Header 

Compressio 

n 

or No 

Adaptation 

Transparent 


Unack 


Shared 


SBPSCH/F 


PDTCH/F 


4 rect 


OMSK 


EEP 


PACCH/F 
PTCCH/F 




8PSK 


EEP 


PACCH/F 
PTCCH/F 


C 


SBPSCH/H 


PDTCH/H 


4 rect 


OMSK 


EEP 


PACCH/H 
PTCCH/H 


8PSK 


EEP 


PACCH/H 
PTCCH/H 




Non 
Transparent 

Header 

Compressio 

n 

or No 

Adaptation 

Transparent 


Ack 


Shared 


SBPSCH/F 


PDTCH/F 


4 rect 


OMSK 


EEP 


PACCH/F 
PTCCH/F 




8PSK 


EEP 


PACCH/F 
PTCCH/F 


D 


SBPSCH/H 


PDTCH/H 


4 rect 


OMSK 


EEP 


PACCH/H 
PTCCH/H 


8PSK 


EEP 


PACCH/H 
PTCCH/H 




UEP Unequal Error Protection - EEP Equal Error Protection - OS Operational Scenario Supported 
(1 ) Whether FACCH and PACCH are both needed when multiplexing PDTCH and TCH is FFS 
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A.2.2 Interactive 



Table A.3: Interactive RAB 



PDCP 


RLC 


lUIAC 


Physical Layer 


TCH 
multi 
plexi 

ng 
case 
(clau 

se 
5.1.1) 




Basic 

Physical 

Subchannel 


Traffic Channel 


Dedicated 
Control 
Channel 




Type 


Interleav. 


Mod. 


Coding 




Non 
Transparent 

Header 

Compression 

No 

Adaptation 

Transparent 


Ack 


Dedicated 


DBPSCH/F 


PDTCH/F 


4 rect. 


GMSK 


EEP 


PACCH/F 
SACCH/TF or 
SACCH/TPF + 

EPCCH/F 


1-6 




8PSK 


EEP 


PACCH/F 
SACCH/TF or 
SACCH/TPF + 

EPCCH/F 


1-6 


A 


DBPSCH/H 


PDTCH/H 


4 rect. 


GMSK 


EEP 


PACCH/FH 
SACCH/TH or 
SACCH/TPH + 

EPCCH/H 


1-6 


8PSK 


EEP 


PACCH/H 
SACCH/TH or 
SACCH/TPH + 

EPCCH/H 


1-6 




Non 
Transparent 

Header 

Compression 

No 

Adaptation 

Transparent 


Ack 


Shared 


SBPSCH/F 


PDTCH/F 


4 rect. 


GMSK 


EEP 


PACCH/F 
PTCCH/F 


NA 




8PSK 


EEP 


PACCH/F 
PTCCH/F 


NA 


B 


SBPSCH/H 


PDTCH/H 


4 rect. 


GMSK 


EEP 


PACCH/H 
PTCCH/H 


NA 


8PSK 


EEP 


PACCH/H 
PTCCH/H 


NA 




UEP Unequal Error Protection - EEP Equal Error Protection 
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A.2.3 Background 



Table A.4: Background RAB 



PDCP 


RLC 


MAC 


Physical Layer 




Basic 

Physical 

Subchannel 


Traffic Channel 


Dedicated 
Control 
Channel 




Type 


Interleav. 


Mod. 


Coding 




Non 
Transparent 

Header 

Compressio 

n 

No 
Adaptation 
Transparent 


Ack 


Dedicated 


DBPSCH/F 


PDTCH/F 


4 rect. 


GMSK 


EEP 


PACCH/F 
SACCH/TF or 
SACCH/TPF + 

EPCCH/F 




8PSK 


EEP 


PACCH/F 
SACCH/TF or 
SACCH/TPF + 

EPCCH/F 


A 


DBPSCH/H 


PDTCH/ 
H 


4 rect. 


GMSK 


EEP 


PACCH/FH 
SACCH/TH or 
SACCH/TPH + 

EPCCH/H 


8PSK 


EEP 


PACCH/H 
SACCH/TH or 
SACCH/TPH + 

EPCCH/H 




Non 
Transparent 

Header 

Compressio 

n 

No 
Adaptation 
Transparent 


Ack 


Shared 


SBPSCH/F 


PDTCH/F 


4 rect. 


GMSK 


EEP 


PACCH/F 
PTCCH/F 




8PSK 


EEP 


PACCH/F 
PTCCH/F 


B 


SBPSCH/H 


PDTCH/ 
H 


4 rect. 


GMSK 


EEP 


PACCH/H 
PTCCH/H 


8PSK 


EEP 


PACCH/H 
PTCCH/H 




UEP Unequal Error Protection - EEP Equal Error Protection 
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Annex B (informative): 

RLC/IVIAC Header format Convention 

B.1 GPRS RLC/IVIAC data block header 
B.1 .1 Downlink RLC/MAC data block header 

The Downlink RLC/MAC data bloclc header is formatted as shown in figure B.1. 



8 7 


Bit 
6 5 


4 


3 


2 


1 


Payload Type 


RRBP 


S/P 1 




USF 




PR 


TFI 


FBI 


BSN 


E 


Length indicator 






1 M 


E 




Length indicator 






1 IVI 


E 1 



Figure B.1: Downlink RLC/MAC Data Block header (CS-1, CS-2, CS-3, CS-4) 



B.1 .2 Uplink RLC/MAC data block header 

The Uplink RLC/MAC data block header is formatted as shown in figure B.2. 



8 7 


Bit 
6 5 


4 3 


2 


1 


Payload Type 


Countdown Value 


1 SI 


R 


Spare 


TFI 


Tl 


BSN 


E 


Length indicator 




1 M 


E 




Length indicator 




1 M 


E 1 


TLLI 



Figure B.2: Uplink RLC/MAC Data Block Header (CS-1, CS-2, CS-3 and CS-4) 



B.2 EGPRS RLC/MAC data block header 



B.2.1 Downlink RLC/MAC data block header 

The EGPRS combined downlink RLC/MAC header for MCS-7, MCS-8 and MCS-9 (header type 1) is formatted 
according to figure B.3. 
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Bit 
8 7 6 5 4 


3 


2 1 


TFI RRBP ES/P 




USF 


BSN1 PR 




TFI 


BSN1 1 


BSN2 




BSN1 


CPS 




BSN2 



Figure B.3: Downlink RLC Data Block Header for MCS-7, MCS-8 and MCS-9 

The EGPRS combined downlink RLC/MAC header for MCS-5 and MCS-6 (header type 2) is formatted according to 
figure B.4. 



Bit 
5 4 



TFI 


RRBP 




ES/P 


USF 




BSN1 


1 


PR 


1 


TFI 




BSN1 1 










CPS 


BSN1 



Figure B.4: Downlink RLC Data Block Header for MCS-5 and MCS-6 

The EGPRS combined downhnk RLC/MAC header for MCS-1, MCS-2, MCS-3 and MCS-4 (header type 3) is 
formatted according to figure B.5. 



Bit 
5 4 3 



TFI 


RRBP 




ES/P 




USF 




BSN1 


1 


PR 


1 




TFI 




BSN1 1 




SPB 


1 




CPS 




1 BSN1 1 



Figure B.5: Downlink RLC Data Block Header for MCS-1, MCS-2, MCS-3 and MCS-4 

B.2.2 Uplink RLC/MAC data block header 

The EGPRS combined upHnk RLC/MAC header for MCS-7, MCS-8 and MCS-9 (header type 1) is formatted according 
to figure B.6. 



8 7 


6 


Bit 
5 4 3 


2 


1 


TFI 


Countdown Value 


SI 


R 




BSN1 




TFI 




BSN2 




BSN1 






BSN2 1 


Spare 


RSB 


CPS 1 




Spare 



Figure B.6: Uplink RLC Data Block Header for MCS-7, MCS-8 and MCS-9 
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The EGPRS combined uplink RLC/MAC header for MCS-5 and MCS-6 (header type 2) is formated according to 
figure B.7. 



8 7 


Bit 
6 5 4 3 


2 


1 


TFI 


Countdown Value 


SI 


R 




BSN1 


TFI 




GPS 


BSN1 1 




Spare 




CPS 




Spare 







Figure B.7: Uplink RLC Data Block Header for MCS-5 and MCS-6 

The EGPRS combined uplink RLC/MAC header for MCS-1, MCS-2, MCS-3 and MCS-4 (header type 3) is formatted 
according to figure B.8. 



Bit 

5 4 



TFI 


Countdown Value 




SI R 




BSN1 




TFI 


CPS 




BSN1 






Spare RSB 


SPB 


CPS 



Figure B.8: Uplink RLC Data Block Header for MCS-1, MCS-2, MCS-3 and MCS-4 



B.3 ECSD RLC/MAC data block header 

The RLC/MAC data block headers for ECSD channel coding are identical in uplink and in downlink. 

B.3.1 Uplink and downlink RLC/MAC data block header 

The header formatting is depicted in Figure B-9. 



8 


Bit 
7 6 5 4 


3 


2 


1 




TFI 


P 


PT 


BSN 


BSN 


E 


Length indicator 


E 






Length indicator 






E 1 



Figure B-9. Downlink and uplink RLC/MAC Data Block Header using ECSD. 

All header-fields in Figure B-9 except the P- and PT-fields follows the specification of GPRS and EGPRS. The Length 
Indicator is identical to the EGPRS Length Indicator, and the TFI is identical to the GPRS/EGPRS TFI field. The 
specification of the P- and PT-fields is included below. 

Polling bit. This bit is set if the receiver is polled for an ACK/NAK report. P=0 implies that polling should be ignored, 
while P=l requires that the receiver sends an ACK/NAK report to the transmitter. 

Payload type. If PT=1 then the RLC/MAC block contains user data, and if PT=0 then the RLC/MAC -block contains 
control information. 
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Block check sequences are also defined for data blocks on ECSD channels. However, they are not shown in Figure B-9 
since they are not considered to be part of the header. An 8-bit block check sequence is mandatory for the header while 
a 16-bit block check sequence is optional for the payload. 

Whether the block check sequence on the payload is used or not is negotiated during service setup. 
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Annex C (informative): 

RRC States, IVIAC States and RRC Connection IVIobility 



C.1 Void 



C.2 IVIAC states 

This clause describes the MAC state model for GERAN in lu mode. The model shows the MAC state for the MAC 
control entity of an MS and not for individual radio bearers. What characterizes the different MAC states is how new 
radio resource allocation is performed i.e. by MAC or RRC, using PCCCH/PACCH/PDTCH or FACCH/SDCCH. 



Additional dedicated channel/TBF setup/release 



^ 



Last TBF/SPSCH release 



Additional dedicated channel 
setup/release ^ 



MAC DTM state 



First TBF/SPSCH 
setup 



[Last dedicated cha nnel release 

J 
First dedicated 
channel setup 



-^ >.^.^^ ,. . ■ . , \ Uedicated channel setup* i >^,„„. ■ , , 
^ MAC Dedicated state f<- H MAC Shared state 



Last dedicated 
channel release 



3L 



Last TBF/SPSCH 

release 

y 



First dedicated 
channel setup* 



MAC Idle state First TBF/SPSCH 



setup 



■■^ 



Additional 
TBF/SPSCH 

setup/release 



* Which way dedicated channel setup is carried out is FFS. 



Figure C-2. States of the MAC Control Entity 



0.2.1 MAC-Dedicated state 

The MAC Control entity will be in MAC-Dedicated state when RRC is in RRC-Cell_Dedicated state and a dedicated 
basic physical subchannel is used and no shared basic physical subchannel is established. In MAC-Dedicated state 
MAC has no control functionality. 

C.2.1 .1 Transition from MAC-Dedicated state to MAC-ldle state 

The transition occurs when the last dedicated basic physical subchannel is released. 

C.2.1 .2 Transition from MAC-Dedicated state to MAC-Sinared state 

This transition is FFS. 
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C.2.1 .3 Transition from MAC-Dedicated state to MAC-DTM state 

The transition occurs when a first TBF on shared basic physical subchannel(s) is estabhshed. The establishment of the 
TBF is handled by RRC. 

C.2.2 MAC-Sliared state 

The MAC control entity is in MAC-Shared state when at least one TBF is ongoing but no dedicated basic physical 
subchannels have been allocated. The corresponding RRC state is RRC-Cell_Shared state. 

C.2.2. 1 Transition from MAC-Slnared state to MAC-DTM state 

The transition occurs when the first dedicated basic physical subchannel is set up while maintaining at least one of the 
ongoing TBFs on shared basic physical subchannel(s). 

C.2.2.2 Transition from MAC-Slnared state to MAC-ldle state 

The transition occurs when all TBFs are released. 

C.2.2.3 Transition from MAC-Slnared state to MAC-Dedicated state 

The transition occurs when the first dedicated channel is set up (on the same cell or a different cell) for the MS. TBFs 
from the shared mode are released at transition to dedicated mode. This transition is FFS. 

C.2.3 MAC-ldle state 

The MAC control entity of an MS is in MAC-ldle state when there are no dedicated or shared basic physical 
subchannels. RRC can be in RRC-Cell_Shared state, RRC-GRA_PCH state or RRC-Idle mode. In this state, the MS 
camps on the PCCCH. 

C.2.3. 1 Transition from MAC-ldle state to MAC-Dedicated state 

The transition occurs when the first dedicated basic physical subchannel is established. This transition is FFS. 

C.2.3.2 Transition from MAC-IDLE state to MAC-SHARED state 

The transition occurs when the first TBF on shared basic physical subchannel(s) is established. 

0.2.4 MAC-DTM state 

The MAC control entity of an MS is in this state when it has one or more dedicated basic physical subchannel(s) and 
one or more shared basic physical subchannel(s) allocated. The corresponding RRC state is RRC-Cell_Dedicated state. 

C.2.4.1 Transition from MAC-DTM state to MAC-Dedicated state 

This transition occurs when the last shared basic physical subchannel is released. 

C.2.4.2 Transition from MAC-DTM state to MAC-Shared state 

This transition occurs when the last dedicated basic physical subchannel is released. 
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C.3 Mapping between RRC States and MAC States 

In the following table, it is described the mapping between GERAN RRC and MAC states and possible channel 
combinations. RRC always handles the allocation of DBPSCH and it also controls which SBPSCHs MAC is allowed to 
use. MAC always allocates PDTCHs when using SBPSCHs. The table below shows which protocol is responsible for 
the different procedures in different scenarios. 

Table C.3: Mapping between RRC and MAC states 



Currently Allocated channel(s) 


Allocation of new resources 


Current Control Plane States 


TCH, SDCCH or 
PDTCH on 
DBPSCH 


PDTCH on 
SBPSCH 


TCH, SDCCH 
or PDTCH on 
DBPSCH 


PDTCH on 
SBPSCH 


MAC State 


RRC State 


1 (or more) 


- 


RRC 


RRC 


Dedicated 


CelLDedicated 


1 (or more) 


1 (or more) 


MAC 


DTM 




1 (or more) 


Shared 


CelLShared 


- 


- 


NA 
(Note 1) 


Idle 


- 


- 


NA 


GRA_PCH 


- 


- 


NA 
(Note 2) 


RRC-Idle Mode 



Note 1. A TCH or an SDCCH may be allocated by RRC in RRC-GRA_PCH state and in RRC_Cell_Shared state 

(when receiving a TCH or an SDCCH assignment on PAGCH, MAC enters the MAC_Dedicated state or 
the MAC_DTM state respectively and RRC enters the RRC -CelLDedicated state). 

Note 2. A TCH or an SDCCH may be allocated by RRC through MAC (when receiving a TCH or an SDCCH 
assignment on PAGCH MAC enters the MAC-Dedicated state). 
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